PI Services

Le blog des collaborateurs de PI Services

Windows7 - Windows Seven devant Windows Vista

Windows Seven plus populaire que Windows Vista ? C’est ce qu’affirme une étude menée par Janco Partners. Selon elle, Windows Seven serait désormais le système d’exploitation le plus utilisé au monde après Windows XP.

Neufs mois après leur sortie , le constat est sans appel : 6% de parts de marché pour Vista contre 14% pour Seven. A noter que les calculs de Jenco Partners ont été effectués en prenant pour base la version RTM de Windows Seven.

83030-windows-7-vista-acceptance-rate

83031-windows-xp-7-vista-pdm

Ces données semblent toutefois quelques peu surévaluées. En effet, Microsoft annoncait en Avril avoir “seulement” dépassé les 10% de PDM – près de 15% selon Janco Partners. Net Applications quant à eux comptabilisaient une PDM de 11,68% pour Windows Seven, contre 15,60% pour Vista et 63,41% pour XP.

Malgré tout, au vu de l’évolution de Windows Seven sur le marché des OS, nul doute que la destinée de celui-ci est de se retrouver sur la première place du podium, en lieu et place de notre bon vieux Windows XP.

SharePoint 2007 – Une vulnérabilité permet l’élévation des privilèges au niveau des sites SharePoint

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

SQL Server – Changer l’emplacement par défaut des bases de données utilisateur et systèmes

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

ServerProp

- 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

dbLocation 

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)

configSQL

  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

    SQL Server – Erreur d’activation Service Broker dans MSDB

    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

    Windows 2008/2008R2 – Ouvrir une session localement

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

    image

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

    SCOM - WMI Probe Module Failed Execution

     

    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)

    image

    image

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

    image

    • Selectionnez Ouvrir une instance (ou Open an instance)

    image

    • Tapez __ProviderHostQuotaConfiguration=@ et cliquez OK

    image

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

    image

    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

     

    image

    SCOM - Xian Network Manager Io R2

     

    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

    DirectAccess - Mise en place d'une ferme NLS en version Core virtualisée sous Hyper-V R2

    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 :

    Cmd

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

    sconfig 

    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.

    MMC-Remote-Management

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

    Binding

    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 :

     New-Cluster1 New-Cluster2

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

    New-Cluster-Rules

    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.

    New-Cluster-Membres

    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 :

    DefaultDocument

    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>

    NLS

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

    2008 R2 - Ajouter un pilote d'impression x86 sur un serveur d'impression Windows Server 2008 R2

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

    image

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

    image 

    image

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

    image

    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.

    image

    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.

    image

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

    image

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

    image

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

    image

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

    image

    image

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

    image

    image

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

    image

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

    image

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

    image

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

    image

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

    image

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

    image

    SEP – Préinstaller le client SEP dans une image “Master” de type Ghost

    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)

    clip_image002clip_image004

    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.