PowerShell retourne l’erreur « Search-Mailbox » n’est pas reconnu comme nom d’applet.

Lors de la connexion à Exchange Online d’Office 365 avec PowerShell, la commande Search-Mailbox vous retourne le message d’erreur suivant :

Le terme « Search-Mailbox » n’est pas reconnu comme nom d’applet de commande, fonction, fichier de script ou programme exécutable. Vérifiez l’orthographe du nom, ou si un chemin d’accès existe, vérifiez que le chemin d’accès est correct et réessayez.

Pour régler ce problème, veuillez suivre les étapes suivantes.

  1. Vous connecter au portail Office 365 en tant qu’administrateur.
  2. Dans le menu Administrateur, cliquer sur Exchange. « Search-Mailbox » n'est pas reconnu comme nom d'applet.
  3. Dans le menu, cliquer sur Autorisation. « Search-Mailbox » n'est pas reconnu comme nom d'applet.
  4. Sur la nouvelle page, sélectionner Organization Management, puis sur le crayon pour modifier les paramètres.
  5. Dans la liste des rôles, cliquer sur le plus (+) pour ajouter des rôles. « Search-Mailbox » n'est pas reconnu comme nom d'applet.
  6. Dans la nouvelle fenêtre, mettre en surbrillance Mailbox Import Export et Mailbox Search, puis cliquer sur Ajouter. « Search-Mailbox » n'est pas reconnu comme nom d'applet.
  7. Cliquer sur OK.
  8. Dans la fenêtre Organization Management, cliquer sur Enregistrer. « Search-Mailbox » n'est pas reconnu comme nom d'applet.

 

Vous devriez maintenant être capable d’exécuter les commandes voulues dans PowerShell.

Installation de licences Office 365 sur un serveur Remote Desktop Server (Terminal Server).

La réponse.

Comprendre le fonctionnement des licences émises par Microsoft n’a jamais été une mince affaire. Il semblerait même que les partenaires autorisés et les employés de Microsoft ne savent pas toujours s’y retrouver.

Je voulais installer des licences Microsoft Office sur un serveur Windows 2012 ayant le rôle Remote Desktop Server (RDS), anciennement nommé Terminal Server (TS), d’activé. Après quelques recherches sur internet, où la plupart des informations sont contradictoires, j’ai demandé à mon partenaire Microsoft quel type de licence je pouvais installer sur le serveur en question et sa réponse a été la suivante.

Toutes versions d’Office 365 peuvent y être installé, puisque les licences sont par utilisateur et que tu dois te connecter.

Ayant souvent eu des réponses approximatives (pour ne pas dire erronées) de mon partenaire Microsoft, j’ai décidé de pousser un peu plus la recherche et de m’informer auprès du service aux ventes de Microsoft. Le premier représentant avec qui j’ai parlé m’a dit que :

Pour utiliser Office 365 sur un serveur RDS, je devais acheter mes licences via le service Open Licences de Microsoft.

J’ai donc, cherché l’information sur le site d’Open Licences, mais vu l’hésitation que j’avais détectée dans la voix de mon interlocuteur et de la complexité du site d’Open Licences, j’ai tout de même décidé de recommuniquer avec le service aux ventes (en anglais cette fois-ci). Me voilà donc dans un chat avec une autre représentante aux ventes qui finis par me dire que :

Seules les versions ProPlus et E3 d’Office 365 peuvent être installées sur un serveur RDS.

Après toutes ces discussions, je décide d’acheter quelques licences de la version ProPlus qui est la version la plus abordable qui me permette de faire ce que j’ai besoin de faire. Je télécharge et j’installe Office. L’installation va bien et je me réjouis d’avoir trouvé la solution. Je démarre ensuite Excel et je reçois le message suivant :

Cette copie de Microsoft Office 2013 ne peut pas être utilisée sur un ordinateur exécutant les services Terminal Server. Pour utiliser Office 2013 avec un tel ordinateur, vérifiez que vous disposez d’une licence en volume d’Office.

Bon!

Me revoilà au point de départ… J’ouvre un billet sur mon portail Office 365 décrivant mon problème. Je reçois ensuite un appel d’un représentant de Microsoft qui, après avoir bien compris la situation, m’indique que :

Seules les licences E3 et E4 d’Office 365 peuvent être utilisées sur un serveur RDS.

On me conseille alors d’ouvrir un nouveau billet sur mon portail Office 365 pour faire changer mes licences, qui me coûteront donc 8 $ de plus par utilisateurs par mois.


Le billet est ouvert; le lundi suivant, je reçois un appel d’un employé du soutien Microsoft et après avoir expliqué mon problème, mon interlocuteur me dit que :

Je n’ai pas à changer mes licences puisque la version ProPlus peut s’installer sur un serveur Remote Desktop, mais que pour ce faire je devais utiliser l’outil de déploiement de Microsoft Office.

Bonne nouvelle, mais je demande à voir!

Je télécharge donc l’outil de déploiement d’Office.

J’installe l’outil de déploiement dans c:\odt\ et je crée mon fichier confuration.xml comme suit.

<Configuration>
<Add SourcePath="C:\odt\" OfficeClientEdition="32" >
<Product ID="O365ProPlusRetail">
<Language ID="fr-fr" />
</Product>
</Add>
<Property Name="SharedComputerLicensing" Value="1" />
<Display Level="None" AcceptEULA="True" />
</Configuration>

Dans ce fichier, je spécifie :

  • SourcePath correspond au chemin où sera téléchargé Office,
  • OfficeClientEdition j’utilise la version 32 bits selon la recommandation de Microsoft,
  • Product ID, et oui Office ProPlus Retail,
  • Language ID, en français,
  • SharedComputerLicensing, très important! Sans ce paramètre à 1, Office ne pourra pas fonctionner sur un serveur RDS.
  • Display Level et AcceptEULA, configurés de telle façon, l’installation se fera en arrière-plan.

Cliquez ici pour consulter la référence complète.

J’exécute ensuite les deux commandes suivantes pour d’abord télécharger la version d’Office voulue, puis pour l’installer.

setup.exe /download configuration.xml
setup.exe /configure configuration.xml

Eurêka!

J’ai une version d’Office installée sur mon serveur RDS et tout fonctionne. Les utilisateurs détenant une licence Office 365 ProPlus peuvent se connecter et utiliser Office comme bon leur semble. La saga est terminée. Je m’estime chanceux d’être finalement tombé sur quelqu’un de compétent qui a permis à mon employeur d’épargner plusieurs centaines de dollars par années pour des licences inutilement chères.

  Du bon

Lors de l’ouverture d’un billet chez Microsoft, la prise en charge est rapide et complète.

  Comme du mauvais

La science derrière les licences chez Microsoft est tellement compliquée qu’eux même s’y perdent et cette méconnaissance peut entraîner des frais élevés. Lire la suite

Comment décrypter des fichiers (EFS) en lignes de commandes.

En regardant les fichiers de journalisation de mes sauvegardes sur un serveur de fichiers, j’ai remarqué que certains fichiers n’arrivaient pas à être copiés. En investiguant, j’ai compris que certains fichiers étaient cryptés et que les utilisateurs qui utilisaient ces fichiers ne savaient aucunement pourquoi ces fichiers étaient cryptés. J’ai essayé de les décrypter en décochant l’option de cryptages dans les propriétés avancées des fichiers (voir image ci-dessous), en tant qu’administrateur de réseau, sans succès.

Propriétés avancées

Après plusieurs recherches, j’ai pu déterminer pourquoi ces fichiers étaient cryptés. Les fichiers proviennent d’un ordinateur Mac et ont été zippés, puis envoyés par courriel. Ensuite, l’utilisateur extrait les fichiers en utilisant l’utilitaire de compression natif de Windows 7. Le problème est en fait que Mac (possiblement tout système Unix) ajoute des attributs aux fichiers ZIP qui sont mal interprétés par Windows.

[…] it just so happens that in POSIX, the flag to describe a directory/folder (S_IFDIR) coincidentally also has the value 0x4000. […]

Consulter l’article.

C’est bien beau tout ça, mais comment puis-je décrypter ces fichiers?
J’ai créé un script Batch avec une commande cipher /D pour chaque fichier/dossier que j’ai exécuté en tant que l’utilisateur qui avait extrait les fichiers.

cipher /D "\\serveur\partage\dossier1\"
cipher /D "\\serveur\partage\dossier1\fichier1.ext"
cipher /D "\\serveur\partage\dossier2\fichier2.ext"

D’accord, mais comment faire pour éviter ce problème à l’avenir?
Rien de plus simple! J’ai installé un utilitaire ZIP (tel que 7zip) sur le poste des utilisateurs ayant le problème. Les programmes non natifs de Windows que j’ai essayés ont tous été capables d’extraire les fichiers correctement.

AC4BFMP.exe a cessé de fonctionner.

Un problème m’empêchait de jouer au jeu Assassin’s Creed Black Flag en mode multijoueur. Le jeu fonctionnait bien en monojoueur, mais dès que j’essayais de jouer en mode multijoueurs, l’écran devenait noir et restait noir. Je devais alors faire ctrl+alt+suppr pour sortir du jeu et je voyais le message suivant.

AC4BFMP.exe a cessé de fonctionner.

Voici comment j’ai résolu ce problème :

  1. Ouvrir le dossier C:\Users\%username%\Documents\Assassin’s Creed IV Black Flag\ (où %username% peut être remplacé par votre nom d’utilisateur Windows).*
  2. Ouvrir le fichier Assassin4.ini et prendre en note les valeurs des paramètres DisplayWidth et DisplayHeight.
  3. Ouvrir le fichier AssassinBlackFlagMP.ini et remplacer les valeurs des paramètres DisplayWidth et DisplayHeight par celles notées à l’étape précédente.
  4. Enregistrer le fichier
  5. Fermer et rouvrir Uplay.

Eurêka!

* Ce chemin est valide sous Windows 7.