PI Services

Le blog des collaborateurs de PI Services

Installation de Windows (x64) sur une partition GPT

Depuis l’apparition de l’UEFI (Unified Extensible Firmware Interface) supposé à terme remplacer le BIOS, les disques MBR laissent peu à peu leurs place aux disques GPT qui permettent par disque physique la cohabitation de 128 partitions de 9,4 milliards de To ce qui laisse loin derrière le BIOS et ses 4 partitions de 2,2 To par disque…

Lorsque l’on tente de réinstaller Windows via une clé USB sur une partition de disque en GPT l’erreur suivante apparait :

“Windows cannot be installed on this disk. The selected disk is of the GPT partition style.”

Ce message d’erreur bien peu bavard ne dit rien sur la cause de l’échec, si ce n’est que la partition est de type GPT. L’erreur ici vient en fait de la clé USB, n’étant pas reconnue comme un périphérique compatible UEFI, c’est le BIOS qui prend la relève, et celui-ci voit les partitions GPT uniquement comme étant réservées au données, donc impossible d’y installer d’OS.

Cependant, en modifiant la structure des fichiers d’installation de Windows sur la clé USB, l’installation se déroule comme prévue.

Step 1 – Formater la clé en FAT32

Et oui FAT32 est le format utilisé par l’UEFI, inutile de s’inquiéter pour le moment les fichiers d’installation de Windows 7 et 8 ne dépassent pas les 4Go, de plus le mode de compatibilité permet d’utiliser le NTFS.

Step 2 – Copier les fichiers d’installations à la racine de la clé

 

Step 3 – Récuperer le fichier bootmgfw.efi

Depuis une version x64 de Windows installée sur un système UEFI, récupérer le fichier bootmgfw.efi disponible à cet emplacement : C:\Windows\Boot\EFI\bootmgfw.efi

Step 4 – Modifier l’emplacement du fichier boot

Modifier l’emplacement du fichier boot depuis G:\efi\microsoft vers G:\efi.

 

Step 5 – Renommer et déplacer bootmgfw.efi

Renommer bootmgfw.efi en bootx64.efi et le copier vers G:\efi\boot.

Maintenant que la clé est prête, l’erreur apparue plus tôt n’est plus là, et l’installation de Windows peut continuer normalement.

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.

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