Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Problème de pilote x86 sur une architecture x64

Problématique rencontrée :

Lorsque l’on veut ajouter un pilote supplémentaire x86 de type NT/2K/XP à une imprimante sous 2008R2, un message vous avertit que « Windows ne trouve pas de pilotes pour l’imprimante dans le répertoire sélectionné pour l’architecture demandé ».

Les pilotes x64 existent déjà dans Windows, mais celui-ci refuse d’y ajouter les homologues x32.

image

Le problème est dû au nommage des imprimantes qui peut être différent  dans server 2008R2 par rapport au package de pilotes d’origine sur 2K/XP.

Ce problème toucherait les imprimantes dont les pilotes ne sont plus mis à jour pour les OS postérieurs à XP ou Vista, par les constructeurs.

Solution testée : Une HP LaserJet 1320 est nommées HP LaserJet 1320 series  sur NT/2K/XP alors que Server 2008 R2 reconnait les pilotes si le mot « series » disparait.

Pour que le pilote x86 d’une HP Laserjet 2200 series PCL 5e soit accepté sur Serveur 2008 R2 il faut que celui-ci désignent une HP Laserjet 2200 series PCL 5 simplement.

Capture0

Pour cela il faut récupérer les pilotes authentiques NT/2K/XP x86, dé zipper, modifier le fichier .inf en renommant l’ancienne appellation de l’imprimante par celle attendu par Windows.

Capture2

Après un petit message d’avertissement le pilote est installé, ce qu’on peut vérifier dans le gestionnaire d’impression.

image

Cette astuce permet d’utiliser le pilote d’origine si de plus récent de type PCL 6 ou HP Universelle existe et ne donne pas satisfaction.

SCOM 2007: MAJ du Management Pack Exchange 2010 !

 

Cette mise a jour du management pack  disponible a l’adresse ci-dessous, prend en charge les apports du Service Pack 1 d’Exchange 2010.

  • Exchange Server 2010 Monitoring Management Pack (14.02.0071.0)

    Au menu:

  •   

  • De nouveaux rapports de performance et de capacity planning ciblé sur chaque serveur et sur l’utilisation réel de ceux-ci.
  • Deux nouveaux rapports sur les connexions clientes SMTP et la fonctionnalité Remote Powershell
  • Un nouveau moniteur de type transaction (Test-SMTPConnectivity) chargé de tester de tester la connectivité SMTP des mails sortant depuis les client IMAP et POP.
  • Une vue dédiée a la connectivité ECP (Exchange Control Panel)
  • De nouveaux scripts chargé de superviser l’indexation et l’espace disque des boites aux lettres.
  • La possibilité de désactiver la résolution automatique d’alerte pour les environnement SCOM contenant des connecteur, permettant ainsi la création de ticket d’incident sur un système tiers avant que l’alerte ne soit résolu.
  • Supervision des process s’arrêtant de manière répété
  • Ajout de plusieurs metrique de performance pour Outlook Web App
  • Amélioration de la supervision de l’acces a Active Directory
  • Ajout de la supervision du partage de calendriers anonymes
  • Ajout de la supervision du moteur de base (ESE)

OCS 2007 R2 – Erreurs lors de la publication de CWA à travers IAG/UAG

Symptôme

Suite à la publication de l’interface Communicator Web Access à travers un équipement de type “reverse proxy” (ISA/TMG ou IAG/UAG), l’erreur suivante se produit de manière aléatoire (environ 1 fois sur 3) :

Cannot sign in because your computer clock is not set correctly or your account is invalid

Voici l’intitulé exact de l’erreur :

Cannot sign in because your computer clock is not set correctly or your account is invalid.(Error code: 0-1-492)

Explication

Cette erreur est un “classique” sur CWA. Elle se produit souvent lorsque l’URL utilisé pour accéder au service Web ne correspond pas au certificat positionné dans IIS ou bien encore aux URL d’accès publiées durant la configuration OCS (étape 4 de l’assistant d’installation du rôle CWA).

image

Cette erreur peut également se produire lorsque les SPN du compte ordinateur sont mal configurés et ne contiennent pas le SPN correspondant à l’URL publiée. Pour cela le SPN manquant peut être rajouté en suivant la procédure suivante :

    Dans ce cas précis, la bonne URL est utilisée lors de l’accès et les SPN du serveur hébergeant CWA sont correctement configuré ! De plus l’erreur ne se produit pas systématiquement mais de manière aléatoire, et ce, uniquement à travers un équipement de type “reverse proxy” (comprendre l’accès à CWA depuis le LAN fonctionne systématiquement et sans aucune erreur) !

Résolution

Après quelques recherches sur le Web, je suis tombé sur le billet suivant qui propose d’activer l’authentification de type Anonyme sur l’une des pages du site CWA (page AuthMainCommandHandler.ashx).

http://www.tincupsandstring.com/2009/03/31/cwa-error-code-0-1-492/

Dans notre cas, cette manipulation a totalement corrigé le problème rencontré avec les publications de CWA à travers Unified Access Gateway (UAG) et Intelligent Application Gateway (IAG).

Configurer la page AuthMainCommandHandler.ashx

Configurer la page AuthMainCommandHandler.ashx

Remarque : A priori ce problème peut également être rencontré lors de la mise en place d’un load balancing matériel (HLB) sur le site CWA (cf. Blog Technet de Stefan Plizga).