Contexte et problème 

Dans Microsoft Office 365/ Office 2016, un délégué dispose des autorisations "Editeur" sur un calendrier d’un autre utilisateur dans Microsoft Outlook.

Le délégué peut créer des rendez-vous/réunions mais lorsqu’il tente de supprimer un élément du calendrier, le message d'erreur suivant s'affiche :

Cause

Lorsqu'un élément de calendrier est supprimé, Outlook 2016/365 tente de le déplacer vers le dossier "Éléments supprimés" de la boîte aux lettres d'origine. Si le délégué ne dispose pas des autorisations sur le dossier Éléments supprimés, l'opération échouera.

Solutions de contournement 

• Utiliser Outlook sur le Web pour supprimer les entrées du calendrier --> Il s’agit de la solution la plus simple
• Comme solution de contournement dans Outlook 2016/O365, attribuer au délégué au moins des autorisations d'auteur sur le dossier "Éléments supprimés"
• Dans les versions antérieures d'Outlook, ce problème ne se pose pas puisque les éléments supprimés étaient déplacés vers la boîte aux lettres des délégués. Ce comportement est contrôlé via la clé de registre DelegateWasteBasketStyle qui se trouve sous :Ordinateur\HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\options\general Cette clé peut avoir les valeurs : 4 – déplace les éléments supprimés vers le dossier Éléments supprimés dans la boîte aux lettres d'origine. 8 – déplace les éléments supprimés vers le dossier Éléments supprimés dans la boîte aux lettres du délégué (Par défaut, Outlook 2016 définit cette valeur clé sur 4) --> Comme une autre solution de contournement, il est possible de modifier la valeur de cette clé de registre à 8.

Scenario:

L'utilisateur avait Office 2016 32 bits installé et souhaite faire une mise à niveau vers le client M365 v2008 (semi-annual channel).

Problème:

Lors de la mise à niveau, l'erreur 0x80077562 (-2146994846) s'affiche dans le centre logiciel MECM --> Tous les produits office ont cessé de fonctionner et Office 2016 n'a pas été supprimé des programmes.

Lorsque vous essayez de désinstaller manuellement l'ancienne version d'Office 2016, cette erreur s'affiche :

"La langue de ce package d'installation n'est pas prise en charge par le système"

Explication:

Cette erreur est parfois causée par l'échec des précédentes tentatives d'installation/désinstallation du produit Office.

Solution:

1. Réinstallez Office 2016 32 bits à l'aide des sources d'installation d'Office

2. Réessayez l'installation d'Office 365 à partir du centre logiciel

Description

Dans les dernières mises à jour des versions Microsoft Office 2016,  lorsqu’un utilisateur ajoute un nouveau compte Exchange 2016 , il est invité à plusieurs reprises à saisir son nom d’utilisateur et son mot de passe pour aboutir finalement à un échec.

Ce problème est lié à la configuration de découverte automatique qu'Outlook utilise. Microsoft semble avoir défini Outlook pour utiliser leurs serveurs Office 365 comme point de configuration initial indépendamment de la façon dont la découverte automatique est configurée.

Résolution

La résolution consiste à définir une entrée du Registre sur l’ordinateur qui rencontre le problème ayant la valeur dessous:

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

Attention: Cette modification ne doit se faire que si un compte Exchange On-Premise est utilisé.

Lancer un script Powershell via le planificateur de tâches ne pose aucun problème, en revanche si ce dernier souhaite utiliser Excel (par l'intermédiaire de la commande "new-object -comobject excel.application") on peut rencontrer un problème.

Je dis "on peut" car cela fonctionne si l'on a pas coché la case "Run Whether user is logged on or not", en revanche si cette dernière est cochée, Excel ne sera pas en mesure d'enregistrer le fichier.

Pourquoi ?

Par défaut l'application Excel s'exécute avec le compte "Utilisateur exécutant (The Launching User)", mais si j'utilise une tâche planifiée qui ne nécessite pas que je sois connecté Excel ne parvient pas a déterminer qui fait appel à lui.

Que Faire ?

Simplement en déclarant qui  exécute l'application Excel via la MMC -> Services des composants.

Je vous renvoie au point 2 (Gestion de l'Excel distant) de mon précédent article : [Powershell] Ecrire dans un Excel distant.

Exécuter Excel sur un poste Distant.

Quel est l'interêt ?

En dehors du fait qu'installer Excel sur un serveur n'est pas forcément une bonne pratique, dans mon cas cela me permet d'automatiser à 100% mes scripts Powershell, ces derniers fournissent des rapports détaillés à mes interlocuteurs, sans que je n'ai besoin de faire quelques modifications que ce soit (contrairement à un CSV).
Ainsi les scripts tournent de nuit et permettent à chacun de trouver son rapport le matin en arrivant, et ce même pendant mes vacances.

Comment ça marche

Pour exécuter Excel sur un poste distant via Powershell il faudra cumuler 2 paramètres.

1. Activer CredSSP pour la délégation des identifiants.
2. Autoriser le compte d'exécution à se servir de l'application Excel à Distance.

Voyons comment réaliser cela.

1- Activer CredSSP

J'ai déjà traité le sujet ICI.

2- Gestion Excel Distant

Attention la modification que nous allons réaliser n'est pas sans conséquence, comme nous pourrons le voir après, l'application Excel devient vraiment limitée pour tout autre utilisateur que celui qui sera déclaré.

Pour pouvoir autoriser le compte d'exécution à se servir de l'application Excel à distance, nous aurons besoin de la MMC.

Sur la machine qui traitera le fichier Excel :

• Ouvrir la MMC > Ajouter ou supprimer des composants logiciels enfichables > Services de composants.

• Développer Services de composants > Ordinateurs > Poste de travail > Configuration DCOM

• Sur "Microsoft Excel Application" faites clic droit "propriétés", dans la fenêtre sélectionnez l'onglet "Identité"

• Cochez la case "Cet utilisateur" puis faites "parcourir", sélectionnez "Tout l'annuaire" et enfin recherchez le compte d'exécution du script.

• Entrez le mot de passe de votre compte d'exécution et faites "Appliquer".

Maintenant que le paramètre est fixé seul le compte définit est "autorisé" à se servir de l'application Microsoft Excel, l'expérience pour tout autre utilisateur est vraiment dégradé (pas d'impression, de sauvegarde, message d'erreur...); par conséquent si vous souhaitez pouvoir continuer à utiliser Excel, je vous invite à repasser sur "L'utilisateur exécutant" et n'activer la fonction que lors de l'exécution du script (pour ma part je ne l'active sur mon poste que la nuit).

Exemple de message d'erreur.

Annexe

En annexe un petit article sur la gestion d'Excel en Powershell :

https://blog.piservices.fr/post/2013/03/27/Powershell-Creation-de28099objets-personnalises

Problème:

Les clients Outlook n'arrivent plus à accéder à la GAL sur Exchange, et donc les utilisateurs sont dans l'incapacité d'ajouter des salles de réunions ou de rechercher contacts qui ne sont pas dans leur cache Outlook. Le client se fige et le message d'erreur suivant apparait après quelques dizaines de secondes:

Troubleshooting:

• Vérification des journaux d'événements .
• Vérification de la réplication AD et Exchange.
• Régénération de l'OAB et MaJ de la GAL. 
• Déplacement de la boite mail contenant l'OAB vers un autre serveur.
• Entrée dans le fichier host pour pointer directement sur le serveur hébergeant l'OAB.
• Test d'accès sur l'URL EWS et l'URL OAB.
• Vérification des logs IIS.

Solution:

Des erreurs 401 étaient retournées depuis le serveur dans les logs IIS. Pour résoudre cette erreur il a fallu redémarrer les services IIS, puis les services "RPC Client Access" et "MS Exchange Throttling", puis de nouveau redémarrer les services IIS.

Contexte

Depuis le client Skype Entreprise 2016 lorsque vous souhaitez afficher les conversations archivées qui se trouvent dans Outlook vous obtenez l’erreur suivante : Votre profil Outlook n'est pas correctement configuré.

Explication

Si l’on regarde la configuration du client Skype, on remarque que la connexion MAPI n’est pas active :

Si l’on utilise le même compte sur un client Skype for Business 2015 (Suite Office 2013), la connexion se faite correctement :

D’après Microsoft, l’erreur provient de la nouvelle méthode de mises à jour du cache MAPI. Dans les versions antérieures à 2016, les connexions MAPI étaient écrites dans le registre et le client Skype allait lire ces informations.

Source : https://support.microsoft.com/en-us/kb/3147130

Solution

La solution consiste à écrire manuellement dans le registre la configuration nécessaire au client Skype pour sa connexion MAPI.

Premièrement nous allons récupérer le LegacyDN de notre compte via l’outil de configuration automatique de la messagerie d’Outlook.

Ensuite deux possibilités :

• Télécharger l’outil de fix de Microsoft à ce lien
• Faire la modification manuellement

Via l’outil de Microsoft

Télécharger et lancer l’outil. Séléctionner Advanced pour lancer l’outil en mode administrateur.

Copier le LegacyDN (sans <LegacyDN> et </LegacyDN>) et cliquer sur Next.

Fermer le client Skype et relancer-le.

Manuellement

Dans la base de registre, trouver la clé KEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\9375CFF0413111d3B88A00104B2A6676\

Rechercher quelle sous-clé contient les informations du compte, dans le cas présent c’est la clé 00000002. Il faut ensuite repérer la valeur de Service UID.

Localiser la clé KEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\<Service UID>

Dans notre cas KEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\ 5b07c5bbc8f4f0438cf8c44ec42c4d46.

Ajouter une nouvelle valeur de type String nommée 001e6603 et contenant la valeur du LegacyDN (sans <LegacyDN> et </LegacyDN>).

Fermer le client Skype et relancer-le.

Vous utilisez les objets COM pour la manipulation de Excel en Powershell et vous souhaitez colorer une cellule sur votre Excel.

Voici un petit script qui va vous permettre d’identifier l’index associé à sa couleur pour la valeur de la commande .Interior.ColorIndex

$Excel = New-Object -ComObject excel.application

$Excel.visible = $true

$workbookHEBDO = $Excel.workbooks.add()

$serverInfoSheetHEBDO = $workbookHEBDO.Worksheets.Item(1)

$excel.cells.item(1,1) = "COLOR"

$excel.cells.item(1,1).Interior.ColorIndex =48

$excel.cells.item(1,1).Font.Bold=$True

$excel.cells.item(1,2) = "Number"

$excel.cells.item(1,2).Interior.ColorIndex =48

$excel.cells.item(1,2).Font.Bold=$True

for ($i=1; $i -le 56; $i++)

{

$excel.cells.Item($i+1, 1).Interior.ColorIndex = $i

$excel.cells.item($i+1,2) = $i

}

Résultat :

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

Contexte

Suite au déploiement de Lync Server 2013, certains clients souhaitent améliorer la visibilité du produit au sein d’Outlook en rajoutant une icône dans la page d’accueil Outlook (par défaut pour créer une réunion Lync, il faut aller dans la partie calendrier).

Problématique

Cette personnalisation d’Outlook n’existe pas dans les modèles d’administration / personnalisation  d’Office (http://www.microsoft.com/en-us/download/details.aspx?id=35554). Cependant il est possible de déployer ce paramètre par GPO.

Solution

N.B : Cette solution a été testée sous Outlook 2010 et 2013.

Lors de la personnalisation du ruban d’Outlook ce dernier créer le fichier olkexplorer.officeUI. Ce fichier se trouve à l’emplacement suivant :

• Sous Windows XP : %Userprofile%\Local Settings\Application Data\Microsoft\Office\
• Sous Windows 7/8/8.1 :  %userprofile%\AppData\Local\Microsoft\Office\

Il suffit alors de personnaliser le ruban depuis un poste et de récupérer le fichier olkexplorer.officeUI.

Le déploiement du fichier se fait ensuite via un script lancé au démarrage du poste via GPO.

Avant :

Après :