Exemples de tickets clients.

Tickets d'assistance traités plus rapidement par les équipes américaines, couvrant tous les logiciels Microsoft

Les témoignages soigneusement sélectionnés ou même les appels de référence avec des clients professionnels sympathiques ne vous donnent pas vraiment une idée des véritables capacités d'un partenaire potentiel. Nous avons trouvé un moyen de donner aux professionnels de l'informatique en entreprise une meilleure idée de ce que nous faisons : leur donner accès aux détails de nos tickets de dépannage Microsoft.

Vous trouverez ci-dessous quelques exemples de tickets Microsoft Enterprise Support réels qui vous donneront une idée du type de problèmes techniques que nous traitons quotidiennement. En plus d'une couverture complète du portefeuille Microsoft, les entreprises bénéficient d'une résolution 50 % plus rapide que MS Premier/Unified. Tout cela est assuré par des équipes basées aux États-Unis et soutenu par les seuls accords de niveau de service (SLA) du secteur en matière de temps de réponse et d'escalade.

Tickets d'assistance chez US Cloud

Azur

Azur

Problème : un utilisateur signale que sa machine virtuelle Azure (VM) ne démarre pas après avoir redimensionné les ressources de la VM, telles que le processeur ou la mémoire. L'utilisateur avait arrêté la VM avant de la redimensionner et avait suivi la procédure documentée pour le redimensionnement. Après avoir redimensionné et démarré la VM, le portail Azure indique que la VM est en cours d'exécution, mais l'utilisateur ne parvient pas à s'y connecter à l'aide du protocole RDP (Remote Desktop Protocol).

Résolution : après avoir examiné le problème, il s'est avéré que l'agent de machine virtuelle sur la machine virtuelle Azure ne répondait pas correctement. Cela était dû à l'opération de redimensionnement des ressources qui perturbait la communication entre l'agent de machine virtuelle et le contrôleur de structure Azure. Pour résoudre le problème, l'agent de machine virtuelle a été redémarré manuellement à l'aide du module Azure PowerShell. Après le redémarrage de l'agent, la machine virtuelle a pu démarrer correctement et l'utilisateur a pu s'y connecter à l'aide du protocole RDP.

Azur

Problème : un client signale que ses ensembles de machines virtuelles Azure (VMSS) ne s'adaptent pas à la demande accrue sur son site web pendant les heures de pointe. Il a vérifié ses politiques de mise à l'échelle et s'est assuré qu'elles devraient s'adapter, mais les instances VMSS ne sont pas créées.

Résolution : l'équipe d'assistance Azure examine le problème et découvre que les règles d'autoscaling sont configurées pour utiliser la métrique « utilisation moyenne du processeur », qui n'augmente pas pendant les heures de pointe en raison d'autres facteurs. Pour résoudre le problème, l'équipe recommande de modifier les règles d'autoscaling afin d'utiliser une métrique différente, telle que « requêtes par seconde », qui reflète mieux l'augmentation de la demande du site web. Le client met en œuvre cette modification et les instances VMSS commencent à s'adapter avec succès pendant les heures de pointe. Le problème est résolu.

Azure Intune

Problème : le client tentait de définir des stratégies pour les appareils gérés par Intune en deux phases afin de forcer le traitement des mises à jour Windows. Les stratégies ont été appliquées, mais les appareils concernés ne réagissaient pas. Le client a ouvert un ticket auprès de US Cloud afin d'examiner les stratégies et de déterminer ce qui pouvait manquer pour que les appareils traitent les mises à jour en attente.

Résolution : US Cloud a étudié le problème et a ensuite informé le client que le problème provenait probablement de l'application Microsoft Teams Rooms (MTR). MTR intègre une logique pour une fonctionnalité Windows 10 qui n'autorise les mises à jour (pour les appareils exécutant Microsoft Teams Rooms) que six mois après la publication d'une mise à jour Windows. Pour ce faire, un blocage spécial est mis en place pour les appareils Microsoft Teams Rooms sur le canal Windows Update for Business (c'est-à-dire le canal semestriel) et via les paramètres de l'application. Pendant cette période de blocage, Microsoft effectue divers tests en interne et via ses partenaires OEM afin de s'assurer que la nouvelle fonctionnalité Windows 10 fonctionne en harmonie avec l'application Microsoft Teams Rooms et les périphériques qui y sont connectés.

Cette mesure est importante pour garantir la sécurité des appareils, une expérience utilisateur cohérente et la qualité des expériences offertes par l'application Microsoft Teams Rooms. Le problème et sa cause ont été expliqués en détail au client et le service informatique a pu réajuster ses attentes concernant ces mises à jour retardées.

Azure AD

Problème : sur un serveur Windows exécutant Azure AD Connect, le processus de synchronisation ne fonctionne pas correctement. L'état de synchronisation indique que la dernière synchronisation n'a pas abouti et que les modifications apportées dans Active Directory sur site ne sont pas répliquées dans Azure AD.

Résolution : après avoir vérifié l'installation d'Azure AD Connect et confirmé que le service fonctionnait, il s'est avéré que le problème était lié aux paramètres du pare-feu. Les ports nécessaires à la communication avec Azure AD n'étaient pas ouverts dans le pare-feu Windows. Pour résoudre le problème, les ports requis ont été ouverts dans le pare-feu en créant des règles entrantes et sortantes. Une fois ces modifications apportées, le processus de synchronisation s'est déroulé avec succès et les modifications apportées à Active Directory sur site ont été répliquées dans Azure AD.

Azure DevOps

Problème : au cours du processus de déploiement, un pipeline Azure DevOps n'a pas pu s'exécuter, ce qui a entraîné un retard dans la publication de l'application. Le message d'erreur indiquait qu'un package requis était manquant, mais la raison pour laquelle ce package était introuvable n'était pas claire.

Résolution : Le problème a été résolu en ajoutant le paquet manquant aux dépendances du projet et en reconstruisant l'application. De plus, le pipeline a été mis à jour afin d'inclure une vérification de toutes les dépendances requises avant l'exécution, ce qui a permis d'éviter des problèmes similaires à l'avenir. L'équipe a également mis en place des tests automatisés afin de détecter tout problème avant qu'il ne provoque des retards dans le processus de publication.

Gestionnaire de ressources Azure

Problème : lors du déploiement d'un nouveau modèle Azure Resource Manager (ARM), le déploiement échoue et un message d'erreur indique qu'une ressource n'a pas pu être créée ou mise à jour.

Résolution : pour résoudre le problème, le groupe de ressources a été vérifié afin de s'assurer qu'il existait et que les autorisations appropriées lui avaient été attribuées. Il a été constaté que les autorisations nécessaires faisaient défaut. Les autorisations appropriées ont donc été accordées à l'utilisateur et au principal de service concernés. Le déploiement a ensuite été réessayé et s'est déroulé avec succès. La ressource a été mise à jour comme prévu.

Microsoft 365

M365 Défenseur

Problème : M365 Defender ne détecte pas les menaces sur les appareils Windows, même si les politiques appropriées sont en place et que les appareils sont à jour.

Résolution : Le problème a été résolu en vérifiant les paramètres de M365 Defender et en s'assurant que toutes les politiques étaient correctement configurées. L'étape suivante consistait à vérifier si les dernières mises à jour de Windows Defender étaient installées sur les appareils concernés. Après avoir confirmé que les mises à jour étaient installées, les appareils ont été à nouveau analysés à la recherche de menaces, et le problème a été résolu. Enfin, des mesures supplémentaires ont été mises en place pour garantir que M365 Defender surveillait et détectait en permanence les menaces sur tous les appareils Windows.

M365 Power BI

Problème : un utilisateur a signalé que son tableau de bord Power BI ne s'actualisait pas automatiquement, alors qu'il avait configuré l'actualisation automatique selon un calendrier défini.

Résolution : après avoir examiné le problème, il a été déterminé que les informations d'identification de la source de données de l'utilisateur n'avaient pas été enregistrées correctement, ce qui a entraîné l'échec de l'actualisation. Les informations d'identification de la source de données ont été mises à jour avec les informations de connexion correctes et le calendrier d'actualisation automatique a été redémarré. Le tableau de bord a alors pu s'actualiser correctement selon le calendrier défini. Il a été conseillé à l'utilisateur de vérifier à l'avenir ses informations d'identification de la source de données lorsqu'il rencontrera des problèmes similaires.

M365 PowerApps

Problème : le formulaire PowerApps ne soumet pas les données à la liste SharePoint.

Résolution : Nous avons d'abord vérifié que la liste SharePoint était correctement configurée pour accepter les données provenant du formulaire PowerApps. Ensuite, nous avons confirmé que la connexion du formulaire à la liste SharePoint fonctionnait correctement. Nous avons ensuite examiné la fonction OnSelect du bouton de soumission afin de nous assurer qu'elle était correctement liée à la liste SharePoint. Enfin, nous avons vérifié qu'aucune formule ou expression manquante ou incorrecte dans le formulaire ne pouvait être à l'origine du problème. Après ces étapes, nous avons pu soumettre avec succès les données du formulaire PowerApps à la liste SharePoint.

M365 SharePoint

Problème : un utilisateur a signalé qu'il ne parvenait pas à afficher le contenu d'une liste SharePoint dans M365. Chaque fois qu'il cliquait sur la liste, la page se chargeait, mais les éléments de la liste n'apparaissaient pas.

Résolution : notre équipe a examiné le problème et a constaté que l'utilisateur avait modifié par inadvertance les paramètres d'affichage de la liste. Nous avons conseillé à l'utilisateur de sélectionner un autre affichage ou de réinitialiser l'affichage actuel à ses paramètres par défaut. Après avoir suivi nos instructions, l'utilisateur a pu afficher le contenu de la liste sans autre problème. Nous avons également rappelé à l'utilisateur de faire attention lorsqu'il modifie les paramètres de la liste afin d'éviter toute conséquence indésirable.

Équipes M365

Problème : Le client venait de passer à Teams et les erreurs des utilisateurs étaient encore fréquentes. On a découvert que certains messages Teams importants avaient été supprimés accidentellement et que tous les efforts déployés par l'équipe informatique interne pour les récupérer avaient échoué.

Résolution : US Cloud a d'abord obtenu des informations générales et détaillées sur les messages et a confirmé que ceux-ci, ainsi que l'équipe, avaient bien été supprimés et non archivés. Les ingénieurs de US Cloud ont ensuite vérifié si l'instance Microsoft Teams du client avait été configurée avec la fonction « Legal Hold » (conservation à des fins juridiques). Bien qu'il ne s'agisse pas d'une fonctionnalité couramment utilisée par les équipes informatiques, la conservation légale est souvent activée lors de la configuration afin de garantir que toutes les informations et interactions au sein de Teams sont conservées indéfiniment, de sorte que quelqu'un puisse rechercher et exporter les preuves pour un tribunal. La conservation à des fins de litige permet de conserver une copie des données même après leur suppression. Un utilisateur peut toujours supprimer le contenu comme il le souhaite, mais Microsoft continuera à conserver les données dans un emplacement caché auquel seuls les administrateurs peuvent accéder.

L'équipe US Cloud a constaté que la salle Teams supprimée avait bien été sauvegardée dans Litigation et que les messages avaient été restaurés. Les journaux d'audit ont été examinés lors d'un partage d'écran et il a été constaté qu'il n'y avait aucun niveau d'audit pour ce type d'événement particulier. US Cloud a conseillé au client de vérifier du côté d'Exchange et a découvert l'utilisateur qui avait supprimé les messages. Il a ensuite été guidé dans l'ajustement des autorisations pertinentes afin de résoudre le problème et d'empêcher que l'incident ne se reproduise.

M365 Exchange

Problème : un serveur Exchange a cessé d'envoyer ou de recevoir des e-mails. Après investigation, il s'avère que les services de transport du serveur Exchange ont cessé de fonctionner. La cause première du problème provient d'un certificat SSL expiré, nécessaire à la sécurité des communications entre le serveur Exchange et les clients de messagerie.

Résolution : le certificat SSL expiré est remplacé par un certificat valide, et les services de transport Exchange Server sont redémarrés. Le serveur Exchange est ensuite testé pour vérifier le bon fonctionnement de l'envoi et de la réception des e-mails, et il est confirmé que le problème a été résolu. Afin d'éviter que des problèmes similaires ne se reproduisent à l'avenir, un système de surveillance est mis en place pour alerter l'équipe informatique lorsque des certificats SSL arrivent à expiration.

M365 OneDrive

Problème : les utilisateurs rencontrent des difficultés pour synchroniser leurs documents Office avec OneDrive, ce qui entraîne des erreurs de synchronisation. Certains utilisateurs constatent également la création de fichiers en double dans leur dossier OneDrive.

Résolution : après avoir examiné le problème, il s'est avéré que les erreurs de synchronisation étaient dues à un conflit avec le Centre de téléchargement Office. La solution consistait à désactiver le Centre de téléchargement Office, puis à réparer Microsoft Office. Le problème des fichiers en double a été résolu en désactivant la fonctionnalité Fichiers à la demande dans les paramètres OneDrive. Une fois ces modifications apportées, les erreurs de synchronisation et les fichiers en double ont été résolus et les utilisateurs ont pu synchroniser leurs documents Office avec OneDrive sans aucun problème.

Flux M365

Problème : un utilisateur a signalé que son flux Microsoft Flow ne se déclenchait pas alors qu'il remplissait les conditions de déclenchement. Il avait déjà vérifié que la condition de déclenchement était remplie et que son compte disposait des autorisations nécessaires pour exécuter le flux.

Résolution : l'équipe d'assistance a examiné le problème et a constaté qu'il était lié à un bug connu dans le service Microsoft Flow. Elle a appliqué un correctif au serveur concerné, et le flux de travail de l'utilisateur a alors pu se déclencher avec succès. L'équipe a conseillé à l'utilisateur de vérifier le tableau de bord d'intégrité du service Microsoft Flow en cas de futures interruptions ou de problèmes avec le service.

Planificateur M365

Problème : une équipe signale que les attributions de tâches dans Microsoft Planner ne sont pas mises à jour pour les plans partagés. Lorsqu'une tâche est attribuée à un membre de l'équipe, les modifications ne sont pas répercutées en temps réel pour les autres membres de l'équipe. L'équipe a vérifié que tous les utilisateurs sont correctement connectés au plan partagé et disposent des autorisations nécessaires.

Résolution : après une enquête approfondie, il s'avère que le problème provient d'un retard de synchronisation entre le serveur Planner et le cache local de l'utilisateur. L'équipe d'assistance applique un correctif pour améliorer le processus de synchronisation et réduire le retard. De plus, l'équipe conseille aux utilisateurs concernés d'actualiser manuellement leur cache local en supprimant les fichiers temporaires et en redémarrant l'application Planner. Cela garantit que les attributions de tâches sont mises à jour de manière précise et en temps opportun pour tous les membres de l'équipe dans le plan partagé.

Dynamique

Dynamics 365

Problème : les utilisateurs rencontraient des ralentissements lors de l'utilisation de Dynamics 365 dans le client Web. Cela causait de la frustration et ralentissait la productivité.

Résolution : après avoir examiné le problème, nous avons découvert que plusieurs scripts personnalisés s'exécutaient en arrière-plan, mais n'étaient pas optimisés pour les performances. Ces scripts ralentissaient le client Web. La solution consistait à optimiser les scripts personnalisés en supprimant les boucles inutiles, en réduisant le nombre de manipulations DOM et en optimisant les requêtes. Après avoir implémenté les scripts optimisés, les performances du client Web se sont considérablement améliorées et les utilisateurs n'ont plus constaté de ralentissements.

Dynamics AX

Problème : lors de l'installation d'une mise à jour pour Dynamics AX, un message d'erreur s'affiche indiquant que l'installation a échoué en raison de dépendances manquantes. Après avoir vérifié les dépendances, il s'avère que l'un des composants tiers requis n'est pas installé sur le serveur.

Résolution : le composant manquant est identifié et installé sur le serveur. L'installation de la mise à jour est ensuite réessayée et s'effectue avec succès. Le système est testé pour s'assurer que la mise à jour n'a causé aucun problème avec les fonctionnalités de Dynamics AX. Enfin, la documentation est mise à jour afin d'indiquer que le composant nouvellement installé est une dépendance requise pour les installations ou mises à niveau futures.

Dynamics GP

Problème : un utilisateur signale un message d'erreur lorsqu'il tente d'enregistrer une transaction dans Dynamics GP. Le message d'erreur indique que le lot est en cours de modification par un autre utilisateur et ne peut pas être enregistré. Cependant, l'utilisateur confirme qu'il est le seul à accéder au lot.

Résolution : le problème provient d'un verrouillage dans la base de données. L'équipe d'assistance identifie et supprime le verrouillage, permettant ainsi à l'utilisateur d'enregistrer la transaction. L'équipe recommande à l'utilisateur d'effectuer régulièrement des tâches de maintenance de la base de données, telles que des contrôles d'intégrité et la suppression des anciennes données de transaction, afin d'éviter que ce type de problème ne se reproduise à l'avenir.

Dynamique F&O

Problème : un utilisateur de Dynamics F&O a signalé un message d'erreur qui s'affichait lors de l'ouverture d'un formulaire spécifique. Le message d'erreur indiquait un problème avec un objet du formulaire et empêchait l'utilisateur de l'ouvrir. L'utilisateur a essayé d'actualiser le formulaire, de vider son cache et même de redémarrer le système, mais l'erreur persistait.

Résolution : Le problème provenait d'une incohérence dans les données de la base de données Dynamics F&O. L'administrateur de la base de données a exécuté une requête pour identifier l'incohérence spécifique et l'a corrigée. Une fois l'incohérence résolue, l'utilisateur a pu ouvrir le formulaire sans rencontrer le message d'erreur. L'administrateur a conseillé à l'utilisateur de signaler immédiatement tout problème similaire afin d'éviter d'autres incohérences dans la base de données.

Serveur Windows

Serveur Windows

Problème : le client disposait d'un serveur Windows Server 2012 exécutant une tâche répétitive programmée pour redémarrer un serveur chaque semaine. Sans raison apparente, le serveur a commencé à lancer cette tâche plus tôt dans la semaine, puis à nouveau à l'heure prévue.

Résolution : US Cloud a d'abord vérifié que le système n'était pas en mode veille prolongée. De plus, les journaux d'événements ne contenaient aucun événement lié à une perte d'alimentation du noyau, ni aucun événement ID 42. Les ingénieurs d'US Cloud ont demandé au client de supprimer la condition AC de la tâche et de s'assurer qu'il n'y avait pas de paramètres GPO ou de configuration SCCM Reboot Schedule. Le client a réinitialisé le planificateur de tâches afin qu'il soit configuré pour Windows Server 2012 r2, car il était réglé pour 2008. Une fois les modifications effectuées, le client a laissé la tâche s'exécuter avec la modification pendant le week-end et a confirmé que le problème était résolu.

Serveur Windows

Problème : un administrateur Windows Server a signalé que son serveur plantait régulièrement et ne répondait plus. Après enquête, il s'est avéré que le serveur plantait en raison d'un service particulier qui ne répondait plus, mais il n'a pas été possible de déterminer la cause du problème. Il a essayé de redémarrer le service et le serveur, mais le problème persistait.

Résolution : l'équipe a recommandé d'utiliser l'outil de diagnostic de débogage pour identifier la cause du service qui ne répondait pas. Elle a analysé le vidage de mémoire créé par l'outil et a constaté que le problème était causé par une fonction spécifique du service. Elle a examiné cette fonction et a découvert qu'elle tentait d'accéder à une ressource qui n'était plus disponible. Elle a mis à jour la fonction afin qu'elle gère correctement ce scénario, et le serveur a cessé de planter.

Serveur Windows

Problème : une machine virtuelle (VM) Windows Server 2019 n'a pas pu rejoindre le domaine, même après avoir fourni les informations d'identification correctes. Le message d'erreur indiquait un problème de canal sécurisé, qui empêchait la VM d'établir une connexion avec le contrôleur de domaine. L'administrateur a essayé de réinitialiser le compte de l'ordinateur et de restaurer le canal sécurisé à l'aide de la commande Netdom, mais le problème persistait.

Résolution : l'équipe a découvert que l'horloge de la machine virtuelle était désynchronisée de plus de 5 minutes par rapport à celle du contrôleur de domaine, ce qui entraînait une défaillance du canal sécurisé. L'administrateur a mis à jour l'horloge de la machine virtuelle afin qu'elle corresponde à celle du contrôleur de domaine, et la machine virtuelle a pu rejoindre le domaine avec succès. L'équipe a également recommandé de configurer la synchronisation horaire sur la machine virtuelle afin de garantir que l'horloge reste synchronisée avec celle du contrôleur de domaine.

Windows Server - Active Directory

Problème : un administrateur Windows Server a signalé un problème de réplication Active Directory entre deux contrôleurs de domaine. L'administrateur a vérifié la connectivité réseau et la configuration DNS, mais n'a pas réussi à résoudre le problème de réplication. Le canal sécurisé entre les contrôleurs de domaine a été réinitialisé, mais le problème persistait.

Résolution : l'équipe d'assistance a enquêté et a découvert une incompatibilité dans l'identifiant de sécurité (SID) des contrôleurs de domaine. Pour résoudre le problème, l'équipe a recommandé d'effectuer un nettoyage des métadonnées des contrôleurs de domaine afin de supprimer toutes les entrées invalides ou orphelines. Le nettoyage a été effectué, et les SID des contrôleurs de domaine étaient alors compatibles. La réplication a été redémarrée, et les contrôleurs de domaine ont pu communiquer entre eux et répliquer les données Active Directory avec succès, résolvant ainsi le problème.

Windows Server - Fédération AD

Problème : un administrateur Windows Server a signalé des problèmes d'authentification ADFS, les utilisateurs étant dans l'impossibilité de se connecter à l'application fédérée. Après avoir vérifié que les certificats étaient valides et que la relation de confiance entre les serveurs fédérés fonctionnait correctement, l'administrateur a consulté les journaux d'événements et a trouvé des messages d'erreur indiquant que le service ADFS ne parvenait pas à se connecter à la base de données SQL.

Résolution : l'équipe d'assistance a examiné le problème et a constaté qu'il était dû à une mauvaise configuration du compte de service ADFS dans la base de données SQL. L'équipe a recommandé à l'administrateur de vérifier les autorisations du compte de service ADFS dans la base de données SQL Server et de s'assurer qu'il disposait des autorisations appropriées pour accéder aux tables requises. L'administrateur a suivi la recommandation de l'équipe et a mis à jour les autorisations du compte de service dans la base de données SQL. Après cela, le service ADFS a pu se connecter à la base de données et authentifier les utilisateurs sans aucun problème. Le problème a été résolu.

Windows Server - Stratégie de groupe

Problème : un administrateur Windows Server a signalé que les paramètres de stratégie de groupe ne sont pas appliqués aux ordinateurs clients du domaine. L'administrateur a vérifié que les objets de stratégie de groupe sont liés aux unités organisationnelles (OU) appropriées et que les autorisations sont correctement définies, mais les paramètres ne sont toujours pas appliqués. L'administrateur a également vérifié les journaux d'événements sur les ordinateurs clients et a trouvé des messages d'erreur indiquant que le traitement de la stratégie de groupe échoue.

Résolution : après avoir examiné le problème, l'équipe d'assistance a déterminé que celui-ci était dû à une corruption du cache des stratégies de groupe sur les ordinateurs clients. Pour résoudre le problème, l'équipe a recommandé de vider le cache des stratégies de groupe sur les ordinateurs clients en supprimant le contenu du dossier C:\Windows\System32\GroupPolicy. L'administrateur a effectué cette opération sur les ordinateurs clients, et les paramètres de stratégie de groupe ont alors été appliqués avec succès. Le problème a été résolu et les ordinateurs clients recevaient et appliquaient correctement les paramètres de stratégie de groupe.

Windows Server - PowerShell

Problème : un administrateur Windows Server signale que les commandes PowerShell ne s'exécutent pas sur son serveur. L'administrateur a essayé d'exécuter des commandes de base telles que Get-ChildItem et Get-Service, mais elles échouent toutes avec des messages d'erreur indiquant que les commandes ne sont pas reconnues. L'administrateur a également vérifié que la version de PowerShell installée sur le serveur est à jour et que la stratégie d'exécution est configurée pour autoriser l'exécution des scripts.

Résolution : l'équipe d'assistance détermine que le problème est dû à l'absence d'une variable d'environnement nécessaire au bon fonctionnement de PowerShell. Pour résoudre le problème, l'équipe recommande de définir la variable d'environnement PATH afin d'inclure le chemin d'accès au dossier contenant l'exécutable PowerShell. L'administrateur ajoute le chemin d'accès au dossier à la variable d'environnement PATH, et les commandes PowerShell peuvent alors s'exécuter correctement. Le problème est résolu et l'administrateur peut désormais utiliser les commandes PowerShell sur le serveur.

Windows Server - Hyper-V

Problème : nous avons rencontré un problème courant où une machine virtuelle ne parvenait pas à se connecter au réseau sur un serveur Hyper-V. Cela a entraîné des problèmes de communication entre la machine virtuelle et d'autres périphériques réseau.

Résolution : Le problème de connectivité réseau de la machine virtuelle sur le serveur Hyper-V a été résolu en vérifiant la configuration du commutateur virtuel et en mettant à jour les paramètres de la carte réseau de la machine virtuelle. Nous avons constaté que la configuration du commutateur virtuel était incorrecte et devait être mise à jour pour permettre à la machine virtuelle de se connecter au réseau. De plus, nous avons mis à jour les paramètres de la carte réseau de la machine virtuelle afin d'utiliser la configuration réseau correcte.

Windows Server - Bureau à distance

Problème : nous avons rencontré un problème courant où une connexion à un bureau distant échouait sur un serveur Windows. Cela empêchait l'accès à distance au serveur et causait des problèmes de communication entre le serveur et les appareils distants.

Résolution : pour résoudre le problème, nous avons vérifié les journaux d'événements des services Bureau à distance et avons trouvé une erreur indiquant que le listener RDP n'était pas disponible. Nous avons ensuite exécuté un script PowerShell pour redémarrer le service listener RDP, ce qui a résolu le problème et permis l'accès à distance au serveur.

Windows Server - IIS

Problème : nous avons rencontré un problème courant où le serveur Web ne répondait pas sur un serveur Windows avec IIS. Cela empêchait l'accès au site Web et causait des problèmes de communication entre le serveur et les appareils distants.

Résolution : pour résoudre ce problème, nous avons vérifié les journaux IIS et avons trouvé une erreur indiquant que le site Web ne pouvait pas se connecter à une adresse IP spécifique. Nous avons ensuite vérifié la configuration réseau et avons constaté que l'adresse IP n'était pas configurée correctement. Nous avons mis à jour la configuration réseau afin d'utiliser l'adresse IP correcte et avons redémarré le site Web, ce qui a résolu le problème et permis l'accès au site Web.

Windows Server - DFS

Problème : la réplication DFS cesse de fonctionner entre deux machines Windows Server, ce qui empêche la synchronisation correcte des fichiers et entraîne des incohérences dans les données.

Résolution : Nous avons constaté que le problème était dû à un pilote réseau obsolète sur l'une des machines. Après avoir mis à jour le pilote, nous avons redémarré le service de réplication DFS et forcé une synchronisation entre les deux serveurs. Cela a résolu le problème et permis de garantir la synchronisation correcte des fichiers entre les serveurs.

Windows Server - Gestionnaire d'identités

Problème : les utilisateurs ne parviennent pas à se connecter aux applications en raison de problèmes de synchronisation entre Windows Server Active Directory et le système Identity Manager.

Résolution : nous avons découvert que le compte du service de synchronisation ne disposait pas des autorisations suffisantes pour accéder aux ressources Active Directory nécessaires. Nous avons mis à jour le compte du service avec les autorisations appropriées et redémarré le service de synchronisation. Après avoir vérifié que le processus de synchronisation fonctionnait correctement, les utilisateurs ont pu se connecter aux applications concernées sans aucun autre problème.

Sur site

Sur site - System Center

Problème : la console System Center Operations Manager (SCOM) est lente à charger et réagit mollement aux commandes de l'utilisateur.

Résolution : Nous avons identifié que la base de données SCOM rencontrait des problèmes de performances dus à une croissance excessive de la base de données. Nous avons procédé à un nettoyage et à une optimisation de la base de données, qui ont consisté à purger les anciennes données, à réindexer les tables et à mettre à jour les statistiques. Une fois le processus d'optimisation terminé, les performances de la console SCOM se sont considérablement améliorées, et les utilisateurs ont signalé des temps de chargement plus rapides et une meilleure réactivité.

Sur site - SharePoint

Problème : un administrateur Sharepoint signale que les utilisateurs ne parviennent pas à accéder à une bibliothèque de documents spécifique sur le site Sharepoint. L'administrateur a vérifié les autorisations sur la bibliothèque et s'est assuré que les utilisateurs disposaient des autorisations appropriées, mais le problème persiste. L'administrateur a également vérifié les journaux du site et du serveur et n'a trouvé aucune erreur liée à ce problème.

Résolution : après une enquête plus approfondie, l'équipe d'assistance découvre que le problème est dû à des autorisations corrompues dans la bibliothèque. Pour résoudre le problème, l'équipe recommande de réinitialiser les autorisations de la bibliothèque à leurs paramètres par défaut à l'aide de PowerShell. L'administrateur exécute le script PowerShell et vérifie que les autorisations de la bibliothèque ont été réinitialisées. Les utilisateurs peuvent alors accéder à la bibliothèque et le problème est résolu.

Sur site - Exchange

Problème : la base de données MS Exchange ne se monte pas et les utilisateurs ne peuvent pas accéder à leurs e-mails. L'administrateur Exchange a vérifié que la base de données est dans un état d'arrêt correct et qu'il y a suffisamment d'espace disque disponible. Cependant, lorsque l'on tente de monter la base de données, l'opération échoue et un message d'erreur indique que la base de données est corrompue.

Résolution : après avoir examiné le problème, l'équipe d'assistance détermine que la base de données Exchange est corrompue et que les journaux ne sont pas rejoués. Pour résoudre le problème, l'équipe recommande de restaurer la base de données à partir de la dernière sauvegarde et de rejouer les journaux. L'administrateur restaure la base de données à partir de la sauvegarde et rejoue les journaux, et la base de données est montée avec succès. Le problème est résolu et les utilisateurs peuvent désormais accéder à leurs e-mails.

Sur site - BizTalk

Problème : un administrateur BizTalk signale un problème au niveau de l'envoi et de la réception de messages entre deux systèmes. L'administrateur a vérifié que le port d'envoi et les emplacements de réception sont correctement configurés, mais les messages ne sont toujours pas traités. L'administrateur a également vérifié les journaux d'événements et a trouvé des messages d'erreur indiquant que les messages sont suspendus en raison d'une erreur de validation du schéma.

Résolution : après avoir examiné le problème, l'équipe d'assistance détermine que celui-ci est dû à une incompatibilité entre le schéma du message et le schéma attendu par le système destinataire. Pour résoudre le problème, l'équipe recommande de mettre à jour le schéma du message afin qu'il corresponde au schéma attendu par le système destinataire. L'administrateur met à jour le schéma du message et redémarre le port d'envoi et l'emplacement de réception. Les messages sont alors traités avec succès. Le problème est résolu.

Sur site - SQL Server

Problème : un administrateur Windows Server signale qu'une base de données SQL Server sur site ne répond pas et que les utilisateurs ne peuvent pas y accéder. L'administrateur a vérifié que le matériel du serveur fonctionne correctement et qu'il n'y a pas de problèmes de connectivité réseau. L'administrateur a également vérifié les journaux d'erreurs SQL Server et a trouvé des messages d'erreur indiquant que la base de données rencontre des blocages transactionnels.

Résolution : après avoir analysé les informations relatives au blocage, l'équipe d'assistance détermine que le problème est dû à des requêtes conflictuelles provenant de différentes transactions. Pour résoudre le problème, l'équipe recommande de modifier les requêtes SQL afin de s'assurer qu'elles ne sont pas en conflit les unes avec les autres. L'administrateur travaille avec les développeurs d'applications pour modifier les requêtes SQL, et la base de données redevient réactive. Le problème est résolu et les utilisateurs peuvent accéder à la base de données sans aucun problème.

Sur site - Skype Entreprise

Problème : un utilisateur signale qu'il ne parvient pas à afficher les messages dans une salle de discussion persistante dans Skype Entreprise. Les autres utilisateurs peuvent voir les messages, mais pas cet utilisateur. L'administrateur a vérifié que l'utilisateur dispose des autorisations appropriées pour la salle de discussion et que celle-ci fonctionne correctement, mais l'utilisateur ne parvient toujours pas à voir les messages.

Résolution : après avoir examiné le problème, l'équipe d'assistance constate que le client Skype Entreprise de l'utilisateur ne se synchronise pas correctement avec le serveur. Pour résoudre le problème, l'équipe recommande de vider le cache Skype Entreprise de l'utilisateur en supprimant le contenu des dossiers suivants : \Lync et \Lync\sip_USERNAME. L'utilisateur effectue cette opération sur son client, et les messages de la salle de discussion persistante s'affichent alors correctement. Le problème est résolu.

Développeur

Développeur - Navigateur Edge

Problème : lors de l'accès à une page Web à partir d'un autre domaine, le navigateur Edge affiche un message d'erreur indiquant que la page Web est inaccessible en raison d'un problème lié à la politique « Cross-Origin Resource Sharing » (CORS). Cette erreur empêche le chargement correct de la page Web et peut perturber l'expérience de navigation de l'utilisateur.

Résolution : pour résoudre le problème CORS, nous avons activé l'option « Accéder aux sources de données entre domaines » dans les paramètres « Options Internet » de Edge. Nous avons également mis à jour le code côté serveur afin d'inclure les en-têtes CORS appropriés pour autoriser les requêtes inter-origines. Après avoir apporté ces modifications, nous avons testé à nouveau l'application et confirmé que le problème CORS était résolu.

Développeur - Visual Studio

Problème : un développeur a signalé que sa compilation Visual Studio échouait avec une erreur MSB3073, indiquant qu'une commande s'était terminée avec un code de sortie différent de zéro. Cette erreur s'est produite lorsque le développeur a tenté d'exécuter une commande post-compilation qui copiait les fichiers compilés vers un emplacement spécifique du système de fichiers. Le développeur avait confirmé que la commande fonctionnait correctement lorsqu'elle était exécutée manuellement à partir de la ligne de commande.

Résolution : après enquête, l'équipe d'assistance a découvert que l'erreur MSB3073 était due au fait que Visual Studio tentait d'exécuter la commande post-compilation avant d'avoir terminé la compilation de toutes les dépendances du projet. Pour résoudre le problème, l'équipe d'assistance a recommandé d'ajouter une dépendance à l'attribut « BeforeTargets » de la cible « Copy » dans le fichier de projet. Cela a permis de garantir que la commande post-compilation était exécutée après la compilation réussie de toutes les dépendances. Le développeur a apporté cette modification au fichier de projet et a pu effectuer la compilation avec succès sans rencontrer l'erreur MSB3073.

Développeur - Développement .Net

Problème : un développeur .NET a signalé que son application ASP.NET Core générait une erreur System.InvalidOperationException au démarrage avec le message « Impossible de résoudre le service pour le type ». Malgré diverses solutions telles que la reconstruction du projet, le nettoyage de la solution et l'effacement du cache du package NuGet, l'erreur empêchait toujours l'application de démarrer correctement.

Résolution : après avoir examiné le problème, l'équipe d'assistance a constaté que l'erreur était due à une incompatibilité entre les services enregistrés et les dépendances dans l'application. Pour résoudre le problème, elle a recommandé de vérifier la méthode ConfigureServices dans le fichier Startup.cs afin de s'assurer que toutes les dépendances étaient correctement enregistrées. Le développeur a mis à jour le code d'enregistrement, et l'application a alors pu démarrer sans l'erreur System.InvalidOperationException.

Développeur - Outlook

Problème : ce très grand et célèbre détaillant américain centenaire, devenu détaillant en ligne, s'est soudainement rendu compte qu'aucun de ses employés ne pouvait se connecter et accéder à son site SharePoint. L'entreprise utilisait cette plateforme comme principal centre de partage et d'accès aux documents internes, et l'impossibilité d'y accéder perturbait considérablement ses activités.

Résolution : un ticket US Cloud a été ouvert. Après une première réponse rapide et un triage, un ingénieur Premier a été mobilisé le jour même. Après avoir examiné l'activité récente du client, il a été découvert que le certificat des serveurs SharePoint avait été mis à jour très récemment. US Cloud a déterminé que cela était très probablement la cause du problème et a conseillé au client d'importer le certificat « SharePoint Root Authority » dans le magasin de certificats racine de confiance sur tous les serveurs SharePoint. Le client a suivi cette recommandation et la connexion a pu être rétablie pour tous les utilisateurs.

Développeur - Suite bureautique

Problème : un développeur a signalé que sa macro VBA dans Excel fonctionnait lentement et consommait beaucoup de mémoire, provoquant le plantage d'Excel. La macro fonctionnait auparavant sans aucun problème, mais après l'ajout de nouvelles fonctionnalités et l'augmentation de la taille des données traitées, elle n'est plus stable. Le développeur a essayé d'optimiser le code et de réduire la taille des données, mais le problème persiste.

Résolution : Il a été déterminé que les performances lentes et la consommation de mémoire étaient dues à une utilisation inefficace des objets de plage et au calcul répété des formules. L'équipe a recommandé de refactoriser le code de la macro afin d'utiliser des tableaux à la place des objets de plage et d'utiliser la méthode .Calculate pour ne déclencher le calcul des formules qu'une seule fois. Le développeur a apporté ces modifications au code de la macro, et les problèmes de performances et de stabilité ont été résolus. La macro s'exécute désormais efficacement et ne provoque plus le plantage d'Excel.

Obtenez un devis auprès de US Cloud pour que Microsoft réduise ses tarifs d'assistance Unified.

Ne négociez pas à l'aveuglette avec Microsoft

Dans 91 % des cas, les entreprises qui soumettent une estimation du cloud américain à Microsoft bénéficient immédiatement de remises et de concessions plus rapides.

Même si vous ne changez jamais, une estimation US Cloud vous donne :

  • Les prix réels du marché remettent en question la position « à prendre ou à laisser » de Microsoft
  • Objectifs d'économies concrets: nos clients économisent 30 à 50 % par rapport à Unified.
  • Négocier les munitions – prouver que vous disposez d'une alternative légitime
  • Renseignements sans risque – aucune obligation, aucune pression

 

« US Cloud nous a permis de réduire notre facture Microsoft de 1,2 million de dollars. »
— Fortune 500, directeur informatique