PI Services

Le blog des collaborateurs de PI Services

Clients disparaissant aléatoirement dans la console WSUS

Contexte

Lors du déploiement d'un nouveau serveur WSUS, des serveurs ou postes de travail apparaissent et disparaissent de la console sans raison logique au premier abord.

Explication

Si les clients apparaissent et disparaissent de la console par intermittence, le soucis vient probablement du SUSClientID.

Cette situation peut arriver quand un serveur est cloné et que les clés de registre liées au SUSclientID ne sont pas modifiées, ou dans le cas des postes de travail, le problème peut se poser si les postes sont déployés via une image système mal configurée (pas de sysprep). 

Résolution

La solution a ce problème est relativement simple une fois que les différents clients concernés ont été identifiés.

Sur chaque client concerné, supprimez clés de registre suivantes:

  • SusClientId
  • SusClientIDValidation

Ces clés sont situées à la racine de la ruche: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate

Ouvrez ensuite une invite de commande en mode administrateur et exécutez les commandes suivantes:

  • wuauclt.exe /resetauthorization / detectnow
  • wuauclt.exe /detectnow

Il faut refaire ces actions sur chaque poste client/serveur concerné.

Les clients devraient ensuite remonter sans soucis dans la console WSUS.

 

Poste de Travail : Fixer le Navigateur par Défaut

Voici comment fixer le navigateur par défaut de vos utilisateurs.

Via PowerShell:

Exécutez les commandes suivantes à l'ouverture de session utilisateur sous forme de script powershell en fonction de votre choix.

Pour Internet Explorer:

Set-Location HKCU:\
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice' -name ProgId IE.FTP
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice' -name ProgId IE.HTTP
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice' -name ProgId IE.HTTPS

 

Pour Mozilla Firefox:

Set-Location HKCU:\
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice' -name ProgId FirefoxURL
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice' -name ProgId FirefoxURL
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice' -name ProgId FirefoxURL

Vous pouvez aussi le faire par GPO dans "Configuration Utilisateur > Paramètres Windows > Registre"

Powershell : Découverte des postes en DHCP et IP fixes

Qui n'a jamais été confronté à un conflit d'adresse IP dans son réseau?

Le plus énervant quand cela arrive c'est de déterminer qui a une IP fixe sur sa machine alors que l'ensemble du parc est censé être en DHCP.

Afin de se se faciliter la tâche et de ne pas devoir passer sur chaque poste voici un script qui va vous permettre de savoir quels postes sont éteints, quels postes sont en DHCP et surtout lesquels ne le sont pas et avec quelle adresse IP (ou plutôt l'ensemble des configurations de chaque carte réseau).

Les Outils :

Pour ce faire vous aurez besoin d'un fichier texte avec les informations suivantes:

  • La première ligne doit s'appeler "Ordi"
  • le reste du fichier contient le nom de vos machines

Exemple :

Dans mon cas le fichier s'appelle DHCP.txt (le nom sera réutilisé dans le Script)

Une fois que le fichier est créé passons à la seconde partie le script:

Dans votre cas il suffira de modifier les lignes:

  • 3
  • 10
  • 17
  • 18
  • 19 
# Script pour détecter l'état des cartes réseaux

$CSV = "C:\Users\XXX\Documents\DHCP.txt"  # Ici on déclare le chemin d'accès au fichier créé plus tôt

# Import du fichier
Import-Csv -Path $CSV | ForEach-Object {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt

# Test de connexion afin de vérifier que le poste est démarré
If ((Test-connection $Postes -count 2 -Quiet) -eq "True") {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt
$Poste_DHCP = "C:\Users\XXX\Documents\Audit\OK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes en DHCP
$Poste_Off = "C:\Users\XXX\Documents\Audit\NOK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes éteints

# Récupération des paramètres de la ou des cartes réseaux
Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | ForEach-Object {
$IP = $_.IPAddress
$DHCP = $_.DHCPEnabled
if (($DHCP -eq $False) -and ($IP -ne $null)) {Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | Select-Object -Property ServiceName,Description,DHCPEnabled,IPEnabled,IPAddress | fl | Out-File $Destination}
Elseif (($DHCP -eq $True) -and ($IP -ne $null)) {Write-Output "Le poste $Postes est en DHCP" | Add-Content -Path $Poste_DHCP}
}
}
Else {
Write-Output "Le poste $Postes est éteint" | Add-Content -Path $Poste_Off
}}

 

En espérant que cela vous servira.

Le Service Pack 2 pour Windows 7 SP1 et Windows Server 2008 R2 SP1

Suite à l'interrogation d'un client à propos des différentes versions d'OS et de leurs Services Pack, force m'a été de constater que le "Convenience Rollup Update for Windows 7 SP1 and Windows Server 2008 R2 SP1" paru en avril 2016, soit 5 ans après le SP1 (février 2011), n'était pas fourni directement par Microsoft via Windows update.

En effet, ce qui s'apparente à un service pack mais qui n'en est pas un, n'est mis à disposition que sur le "Microsoft Catalog Update".

Ce "CRU" de 316 à 476Mo selon le package, contient un peu plus de 200 mises à jour soit toutes celles depuis le SP1 jusqu'au mois de mai 2016 (à l'heure ou j'écris ces lignes). 

 

Prérequis :

Pour pouvoir installer le Rollup package vous devrez disposer des éléments suivants:

  1. Service Pack 1 for Windows 7 or Windows Server 2008 R2 (KB976932)
  2. April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2 (KB3020369)
  3. 4Go d'espace libre sur le disque
  4. Utiliser Internet Explorer pour le téléchargement (Vous aurez un message comme ci-dessous avec les autres navigateurs)

Sans Internet Explorer

 

Téléchargement :

Pour télécharger le package utilisez Internet Explorer puis rendez vous sur l'URL : Microsoft Catalog Update

Ici un Pop-up vous invitant à installer un module complémentaire apparaît, cliquez sur "installer"

Module à installer

Ensuite à l'aide du menu contextuel recherchez la KB3125574 (vous n'êtes pas obligé d'écrire KB le numéro suffit).

KB3125574

3 packages s'offrent à vous : 

  1. Le premier pour Windows 7 SP1 32 bits
  2. Le deuxième pour Windows Serveur 2008 R2 SP1 64 bits
  3. Le troisième pour Windows 7 SP1 64bits

Sélectionnez celui ou ceux qui vous intéressent à l'aide du bouton "Ajouter"

Packages

Puis cliquez sur "Afficher le panier"

 Panier

Et enfin "Télécharger". Download

Une fenêtre s'ouvre pour afin que vous puissiez indiquer le répertoire de destination de votre téléchargement, à la suite de quoi le téléchargement débutera automatiquement.

Directory

En cours

Fin

 

Une fois ce dernier terminé il ne vous reste plus qu'a vous rendre dans le répertoire que vous avez indiqué plus tôt; dedans se trouvera un ou plusieurs répertoires portant le nom du ou des packages récupérés.

CRU

 

Vous n'aurez plus qu'à ouvrir le "Package autonome Microsoft Update (.msu)" précédemment téléchargé et attendre sagement que les mises à jours s'installent.

Package autonome Microsoft Update (.msu)

Nota bene :

Microsoft n'a prévu aucun correctif pour le navigateur "Internet Explorer", la firme américaine vous propose simplement de télécharger et installer la dernière version disponible et bien entendu de faire les mises à jours via Windows update.

 

 

https://support.microsoft.com/en-us/kb/3125574

https://support.microsoft.com/en-us/kb/3156417

 

 

 

Dysfonctionnement sur Microsoft Office suite à la mise à jour de sécurité MS14-082 (Décembre 2014)

 

Suite à la distribution de la mise à jour de sécurité Office MS14-082 le 9 décembre 2014, vous rencontrez un problème avec l’exécution de vos documents Excel contenant des macros et contrôles ActiveX ? Si la réponse est oui, cet article peut vous intéresser.

Comment se matérialise l’incident ?

Selon l’article officiel disponible ici, Microsoft liste plusieurs symptômes permettant d’identifier l’incident. Pour faire simple suite à l'application de la mise à jour, l’incident vous empêche d’exploiter vos fichiers Office contenant des macros et contrôles ActiveX. Dans notre situation, l’activation du contenu actif d’un fichier Excel contenant des macros était devenue tout simplement impossible.

Dans le détail : L’installation de la mise à jour créée une désynchronisation des bibliothèques de types de contrôle mises en cache (Fichiers portant l’extension .exd)

Vous trouverez ci-dessous les références des mises à jour qui génèrent l’incident :

· Security Update for Microsoft Office 2007 suites (KB2596927)

· Security Update for Microsoft Office 2010 (KB2553154)

· Security Update for Microsoft Office 2013 (KB2726958)

Quels sont les produits impactés ?

Les suites Office 2007, 2010 et 2013 peuvent être impactées par l’installation du correctif. En détail :

· Microsoft Excel 2013

· Microsoft Word 2013

· Microsoft PowerPoint 2013

· Microsoft Visio Standard 2013

· Microsoft Visio Professional 2013

· Microsoft Excel 2010

· Microsoft Word 2010

· Microsoft PowerPoint 2010

· Microsoft Visio Professional 2010

· Microsoft Visio Premium 2010

· Microsoft Visio Standard 2010

· Microsoft Office Excel 2007

· Microsoft Office Word 2007

· Microsoft Office PowerPoint 2007

· Microsoft Office Visio Professional 2007

· Microsoft Office Visio Standard 2007

Comment résoudre le problème ?

Vous pouvez appliquer la solution préconisée ci-dessous :

1. Fermer les classeurs Excel

2. Ouvrir l'explorateur Windows

3. Sélectionner le disque C:

4. Saisir dans la barre de recherche la chaîne de caractères suivante : *.exd

5. Lancer la recherche (attendre que la recherche soit terminée)

6. Plusieurs éléments portant l'extension exd vont être trouvés. Sélectionner et supprimer l'ensemble des éléments trouvés

7. Ouvrez de nouveau votre fichier Excel. Le problème devrait disparaître.

Sources d’informations

Si besoin vous trouverez des informations complémentaires sur les liens ci-dessous :

http://stackoverflow.com/questions/27497444/excel-2010-command-button-no-longer-activate-its-click-event

https://social.technet.microsoft.com/Forums/en-US/b8f0af82-0bb8-4799-aa62-1dbcbc5b7742/excel-2010-macros-does-not-work-after-updates-9dec2014?forum=excel

http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2014/12/11/forms-controls-stop-working-after-december-2014-updates-.aspx

Windows – Changement de domaine Active directory d’un poste connecté en VPN.

 

Comme toute migration ou changement de domaine d’un poste de travail cette opération doit rester la plus transparente possible pour l’utilisateur final.

Cet article aborde la migration d’un poste connecté au réseau d’entreprise par un VPN.

Dans cette situation ce n’est pas la migration du poste qui pose une difficulté, mais l’impossibilité pour l’utilisateur de pouvoir ouvrir une session sur son poste.

Les informations d’authentification du compte (en cache) du domaine Active Directory qu’on peut utiliser même si le domaine n’est pas disponible, ce qu’on décrit comme le mode hors connexion, ne sont plus disponibles après le changement du domaine.

Par défaut Windows 7 cache jusqu’à dix comptes.

Le cache est enregistré dans la ruche suivante : HKEY_LOCAL_MACHINE\SECURITY\Cache.

clip_image002

Pour accéder à cette ruche il faut utiliser un outil tel que PsExec de SysInternal afin de débloquer l’accès.

La ligne de commande est la suivante : psexec -i -d -s c:\windows\regedit.exe

Après le changement de domaine les données mentionnées dans les valeurs NL$ seront supprimées (remises à zéro).

L’utilisateur ne peut donc plus ouvrir de session !

Pour ma part j’ai eu à traiter des utilisateurs travaillant dans des coins très reculés.J’ai eu part exemple le cas d’un VIP travaillant en Australie à plus de 3000 kms d’une agence disposant d’un réseau connecté à l’entreprise. La marge de manœuvre est quasiment nulle…

Pour contourner ce problème je propose deux techniques.

La première technique consiste à démarrer la connexion VPN donc l’authentification avant l’authentification Windows.

Il faut donc avant la migration configurer le client VPN afin qu’il se lance avant l’authentification Windows.

Sur les clients VPN récents de CheckPoint l’option Enable Secure Domain Logon permet ce mécanisme.

clip_image004

Vous verrez un icône supplémentaire dans la fenêtre d’authentification Windows.

Pour information cette option pour le client CheckPoint sur Windows XP n’est pas fonctionnelle.

La seconde technique si l’on ne souhaite pas ou si l’on ne peut pas démarrer la connexion VPN avant l’authentification Windows, consiste à ouvrir une session locale puis à lancer une application qu’on exécute en tant que avec son compte de domaine. Bien entendu la connexion VPN doit être démarrée.

En résumé :

· Création d’un compte local (admin si possible, bien utile pour se sortir de situation délicate) avant la migration.

· Après migration, authentification avec ce compte local.

· Lancer le VPN.

· Lancer une application. Exécuter en tant que (ex Notepad) avec son compte de domaine. (Pour information le RunAS ne fonctionne pas sous XP).

· Fermer la session et ouvrir une session avec son compte de domaine Active Directory.

Le VPN n’étant pas démarré, les informations mis en cache lors du lancement de Notepad exécuté « En tant que » précédemment seront utilisées.

La migration sous un VPN étant très délicate il faut bien entendu bien valider son processus avant de passer au concret.

Je conseille fortement quel que soit le scénario, de créer un compte local admin et de faire installer un outil tel que Team Viewer qui s’affranchit de l’adresse IP pour l’aide à distance.

Powershell : Définir la liste d'adresse par défaut d'Outlook

Problème rencontré

Lors d'une migration Exchange inter organisation visant à la consolidation des infrastructure de messagerie des filiales d'une entreprise, il s'est présenté la problématique suivante. Il fallait que les utilisateurs aient accès dans leur client Outlook à une liste d'adresse correspondant à leur filiale. Cette dernière devait être la liste visible par défaut.

Solution proposée

Pour se faire, il est nécessaire de modifier une clé de registre sur les postes clients.
Dans la ruche : "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\", sont listés les profiles du client Outlook. Une ruche est présente dans chacun de ceux-ci : "9207f3e0a3b11019908b08002b2a56c2". Celle-ci contient la clé "01023d06" qui définit la liste d'adresse qui sera affiché par défaut à l'ouverture du carnet d'adresse. Attention la valeur est encodé au format Bytes HEX. Nous verrons comment la définir.

S'agissant d'appliquer une modification du registre à l'ensemble des postes clients d'une filiale, la solution la plus simple était d'implémenter cela dans le login script. Cela sera fait en Powershell. Il est bien entendu aussi possible de réaliser cette opération en VBS.
 
Il est à savoir que la vue par défaut du carnet d'adresse est la "Global Address List". De plus, si une valeur erronée est inscrite dans la clé de registre (ne correspondant à aucune liste d'adresse) alors Outlook repositionnera automatiquement le carnet d'adresse sur la liste d'adresse globale.

Récupération des paramètres

Afin de connaitre la valeur que nous devons positionner sur la clé "01023d06", il faut paramétrer manuellement Outlook afin de récupérer la valeur que l’on devra positionner. Pour cela, on définit la liste d’adresse sur laquelle on souhaite que nos utilisateurs se trouvent par défaut.

3

Ensuite, on peut ouvrir la clé de registre qui nous intéresse et observer sa valeur.

1

Si l'on modifie plusieurs fois cette valeur, on remarque le phénomène suivant. Elle se découpe en 3 parties :
- Une première qui est généré dynamiquement par utilisateur (avant le trait rouge)
- Une seconde qui est fixe qui va nous être utile pour récupérer la partie dynamique (entre le trait rouge et vert).
- Une troisième partie fixe (après le trait vert).

Ces trois éléments ont toujours une longueur fixe.

Il faut ensuite reformater les deux dernières parties sous forme de tableau de bytes. Il suffit devant chaque valeur en byte d’ajouter “0x” et de mettre une virgule entre toutes les bytes (syntaxe d'un tableau en Powershell).
Exemple :

01 00 00 00 00 01 00 00 2F devient 0x01,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x2F. Dans le script cette valeur sera définit par la variable $GALSuffix.

67 75 69 64 3D 38 42 34 39 43 31 36 34 45 44 35 41 36 34 30 39 34 42 30 42 4236 35 43 34 45 38 46 39 42 39 00 devient 0x67,0x75,0x69,0x64,0x3D,0x34,0x38,0x42,0x34,0x39,0x43, 0x31,0x36,0x34,0x45,0x44,0x35,0x41,0x36,0x34,0x30,0x39,0x34,0x42,0x30,0x42,0x42, 0x36,0x35,0x43,0x34,0x45,0x38,0x46,0x39,0x42,0x39,0x00.

Dans le script cette valeur sera définit par la variable $GALDefaultValue.

Script

Ci-dessous, le script commenté, où l'on va appliquer les paramètres que l'on a récupéré précédemment. Ceux-ci seront comparés avec ceux que l'on retrouve dans la clé de registre "11023d05" qui contient une configuration de sauvegarde. Cela permet de récupérer la première partie qui est dynamique.

2

Entre la ligne 37 et 47 on compare un à un les bytes rencontrés dans la clé de registre "11023d05" afin de retrouver l’index ou se trouve le tableau de bytes contenu dans $GALSuffix. Une fois cette valeur obtenue, on sait que la partie dynamique à rechercher est définie dans les 20 bytes précédentes.

Réaliser un package MSI multi-langues à partir de plusieurs MSI

 

L’objectif de ce tutoriel est de réaliser un package MSI multi-langues à partir de plusieurs MSI de différentes langues. InstallSite et Microsoft fournisse leur propre méthode à base de vbscript. Ici nous utiliserons InstEd.

Dans notre cas présent, nous avons 4 MSI de 4 langues. Nous en garderons un qui servira de référence. Ensuite, nous modifions le MSI de référence pour le rendre multi-langues. Nous générons les MST de chacune des langues. Finalement, nous les stockons dans le MSI de référence.

1. Rendre un MSI multi-langues

  • Ouvrir le MSI de référence avec InstEd
  • Parcourir le menu Tables/Summary info
  • Ajouter au champ « Languages » les langues à venir, par leur LangID et séparer par des virgules.

2. Générer les MST

  • Ouvrir le MSI d’une langue
  • Parcourir le menu Transform/Generate Against…
  • Sélectionner le MSI de référence
  • Enregistrer le différentiel dans un MST. Garder le nom de la langue dans le nom de fichier peut aider à s’organiser.

Répéter ces actions autant de fois que vous avez de langues différentes.

3. Stocker les MST dans le MSI de référence

  • Ouvrir le MSI de référence
  • Ajouter un enregistrement à la table _Storage en choisissant le MST d’une langue en guise de donnée et le LangID du MST pour le nom.

Il est important de respecter cette convention de nommage car c’est une clé du mécanisme Windows Installer permettant de charger le MST correspondant à la langue de l’utilisateur (UserLanguageID ) à l’exécution du MSI.

Répéter ces actions autant de fois qu’il y a de langues. En n’oubliant pas que chaque MST ajouté doit avoir sa LangID associée ajouté au champ « Languages » dans « Summary Info ».

Voilà, c’est fini.

Récupérer les informations de l'utilisateur connecté et réévaluer le chemin d'installation des composants

L’objectif est de récupérer les variables d’environnement de l’utilisateur en cours d’installation d’un package MSI. La difficulté est que l’installation par certain outil de télédistribution installent les packages avec le compte système.

Ci-joint vous trouverez un script vbs permettant de récupérer ces informations. Nous allons décrire les actions suivantes :

  • Ajout du vbscript dans une « custom action »
  • Séquencer cette « custom action »
  • Modifier l’installation d’un composant en fonction d’une variable utilisateur
  • Séquencer cette « custom action »
  • Utilisation de cette nouvelle valeur dans le chemin d’installation du composant

1. Créer une nouvelle « custom action » pour exécuter le vbscript

  • Ouvrir le MSI avec InstEd
  • Ajouter un nouvel enregistrement dans la table CustomAction, de type 38 (0x26 - VBScript - Source: Null - Target: script text | Scheduling: Always).
  • Recopier le contenu du script ci-joint dans le champ Target.

Par exemple :

clip_image003

Voici les variables d’environnement récupérées et les variables « windows installer » affectées :

clip_image005

 

2. Séquencer la « custom action »

Par exemple :

clip_image007

 

3. Créer une nouvelle « custom action » pour modifier les composants à partir des nouvelles informations

  • Ajouter un nouvel enregistrement dans la table CustomAction, de type 35 (0x23 - Directory - Source: Directory to be set - Target: formatted text | Scheduling: Always).

clip_image009

Cette « custom action » va donc affecter au répertoire « LogonUserProfile » la variable windows installer « LogonUserProfile »

 

4. Séquencer la « custom action »

Pas de condition à ajouter, car elle doit être exécutée dans tous les cas, installation, rollback, désinstallation et auto-réparation.

Par exemple :

clip_image011

Par exemple, ici nous avons positionné un fichier dans le profil de l’utilisateur. Ce fichier est contenu dans un composant :

clip_image013

Le chemin d’installation du composant sera donc automatique réévalué à l’installation, rollback, désinstallation et auto-réparation.

Ce principe pourra également être utilisé pour des package MSI x86/x64 pour des composants nécessitant un chemin différent suivant l’architecture du poste de travail.

***************************************

Get_LogonUsersVars.vbs

Option Explicit

Const HKEY_USERS = &H80000003

Dim strKeyPath, subKey, arrKeys

Dim oReg
Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")

Dim oShell
Set oShell = CreateObject("Wscript.Shell")

strKeyPath = "Volatile Environment"

'*** DEBUT DU MAIN ***

oReg.EnumKey HKEY_USERS, "", arrKeys
  
For Each subkey In arrKeys    
    
     If RegExists("HKEY_USERS\" & subkey & "\" & strKeyPath & "\") Then

    Session.Property("LogonUserSID") = subkey

    'Msgbox "User's SID : " & Session.Property("LogonUserSID")

    Session.Property("LogonUserName") = oShell.RegRead("HKEY_USERS\" & subkey & "\" & strKeyPath & "\USERNAME")

    'Msgbox "LogonUserName : " & Session.Property("LogonUserName")

    Session.Property("LogonUserAppData") = oShell.RegRead("HKEY_USERS\" & subkey & "\" & strKeyPath & "\APPDATA")

    'Msgbox "LogonUserAppData : " & Session.Property("LogonUserAppData")

    Session.Property("LogonUserProfile") = oShell.RegRead("HKEY_USERS\" & subkey & "\" & strKeyPath & "\USERPROFILE")

    'Msgbox "LogonUserProfile : " & Session.Property("LogonUserProfile")

                
     End If
 
Next     

'*** FIN DU MAIN ***

' Test d'existence d'une clé de registre
Function RegExists(value)

    On Error Resume Next

    Dim Val
            val = oShell.RegRead(value)

    If (Err.number = -2147024893) or (Err.number = -2147024894) Then
        RegExists = False
    Else
        RegExists = True
    End If

End Function

Windows échoue à se connecter à l’imprimante

Symptômes :

Lors du rapatriement des pilotes un bug se produit et l’assistant s’interrompt (imprimante réseau couleur).

« Windows cannot connect to the printer. Operation failed with error 0x0000007e ».

imageimage

                            image

Ce problème survient lorsque qu’on tente d’ajouter une imprimante couleur sur un poste client Windows 7 rattaché à un serveur d’impression Windows 2003 ou Windows 2008.

Deux solutions de contournements fonctionnent car le problème est connu par Microsoft mais sans correctif pour le moment.

· Le premier s’opère sur le poste client, et consiste à installer l’imprimante en utilisant le port LPT2, puis d’utiliser une commande de redirection

                             clip_image002

· Le deuxième consiste à modifier une clé de registre sur le serveur d’impression. Puis de se connecter à l’imprimante.

Regedit> HKLM\System\CurrentControlSet\Control\Print\Printers\printername\CopyFiles en renommant le répertoire CopyFiles par xCopyFiles. Ce répertoire n’existe que pour une imprimante couleur.

clip_image003

Les deux solutions fonctionnent instantanément. Mais il est beaucoup plus rapide de modifier le répertoire défaillant directement dans la base de registre pour toutes les imprimantes concernées.