danard.net - Poste de travail

Systray Info: information sur votre ordinateur

webmaistre — Sun, 01 Mar 2026 19:17:16 +0000

Ce script PowerShell lance une petite application en zone de notification qui affiche les principales informations de la machine dans une fenêtre WPF/XAML, à la façon de BGInfo, avec gestion d’instance unique et mise à jour dynamique de certaines données.

Les données affichées proviennent de diverses sources accessibles en PowerShell, que ce soit par fonctions intégrées, requête WMI ou lecture du registre.

Tout le contenu affiché est défini par section, comportant un label, les données à afficher, et la fonction à appeler pour récupérer ces données.

Il inclut aussi une fonction de copie des données (plus facilement utilisable qu'une copie-écran).

Mise à jour 2026-03-22:

La fonction déterminant la version de Windows a été corrigée, elle se basait sur la mauvaise entrée de registre.

Un script a été ajouté, permettant de gérer l'affichage des icônes dans la zone de notifications, dans le contexte d'un utilisateur.

Ce script lit les informations stockées dans "HKCU:\Control Panel\NotifyIconSettings", entrée de registre qui contient une liste d'exécutables pouvant afficher des notifications.

Chaque entrée dispose d'une valeur "IsPromoted" qui permet de définir l'état d'affichage: 1 = constamment visible, 0 = masqué.

Dans le cas de scripts PowerShell, le script se base sur le tooltip pour faire la sélection.

Date de publication:

01/03/2026 - 20:17

Dernière modification:

22/03/2026 - 11:34

SysTrayInfo_v2.zip

Interface d'administration

Roland Danard — Tue, 23 Nov 2021 19:43:53 +0000

Trop souvent j'ai eu besoin de travailler sur la même machine en utilisant plusieurs comptes afin d'effectuer des tâches d'administration IT.

S'il est toujours possible de lancer des programmes "en tant que...", cela est vite lassant.

J'ai donc cherché à mettre au point un outil que je pouvais lancer une fois pour y revenir à chaque fois qu'il me fallait exécuter une tâche avec des privilèges différents de ceux possédés par mon compte "bureautique".

La version proposée ici répond pour l'instant à mes besoins.

Elle s'adapte aux outils présents sur le poste de travail standard ou à une machine d'administration, et peut être facilement étendue pour ajouter d'autres éléments, même si par choix pratique leur liste est intégrée dans le code plutôt que de figurer dans un fichier externe.

2023-02-19: Nouvelle version

La nouvelle version permet maintenant de diviser la liste d'outils en plusieurs volets, afin de regrouper les outils suivants les domaines d'utilisation.

Les divers onglets sont définis comme suit:

$tabsList = @(
	[PSCustomObject]@{
		Name       = "ADInfra"
		Label      = "Active Directory & Infra"
		Background = "Aqua"
	}
	[PSCustomObject]@{
		Name       = "ComputerMgmt"
		Label      = "Computer Mgmt Tools"
		Background = "Aquamarine"
	}
	[PSCustomObject]@{
		Name       = "Other"
		Label      = "Other Tools"
		Background = "LightGreen"
	}
)

Les outils sont eux définis comme suit:

$toolsList = @(
	[PSCustomObject]@{
		Name       = "DSAC_EXE"
		Label      = "Active Directory Administration Center"
		FilePath   = $env:SystemRoot + "\System32\dsac.exe"
		Parameters = ""
		TabName    = "ADInfra"
	}
	[PSCustomObject]@{
		Name       = "REGEDIT_EXE"
		Label      = "Registry Editor"
		FilePath   = $env:SystemRoot + "\regedit.exe"
		Parameters = "/s"
		TabName    = "ComputerMgmt"
	}
	[PSCustomObject]@{
		Name       = "CHROME_EXE"
		Label      = "Google Chrome"
		FilePath   = $env:ProgramFiles + "\Google\Chrome\Application\Chrome.exe"
		Parameters = "https://danard.net"
		TabName    = "Other"
	}
}

Pour améliorer l'aspect visuel, la barre de statut utilise la même couleur de fond que la fenêtre principale, et est placée en bas de fenêtre.

Note: contrairement à MS Edge, Google Chrome peut être lancé dans un contexte utilisateur alternatif à celui utilisé pour la session ouverte.

Date de publication:

23/11/2021 - 20:43

Dernière modification:

19/02/2023 - 21:15

AdminUI.zip

Réseau - Détection du type de connexion

Roland Danard — Sun, 17 Mar 2019 17:17:41 +0000

Il est souvent utile de connaître le type de connexion utilisée lors de l’exécution de certaines opérations sur un poste de travail, afin de réaliser ou non certaines opérations.

Par exemple, lors d’une mise à jour d’une version de Windows, il peut être souhaitable de bloquer la mise à jour si elle n’est pas exécutée sur le réseau interne de l’entreprise, ou au minimum d’avertir l’utilisateur des risques de l’opération.

Ou encore, si l’ordinateur est connecté en VPN, la mise à jour du client VPN demandera que la nouvelle version de la solution VPN soit téléchargée dans son intégralité avant que l’installation n’ait lieu…

Le script fourni ici commence par déterminer quelle est l’interface réseau utilisée pour la connexion au domaine, puis vérifie quel est son type, d’après les informations relatives au medium physique : 802.3, 802.11, Bluetooth, …

Les types ne correspondant pas à une connexion filaire ou sans fil sont considérés comme relevant du VPN.

<#
.SYNOPSIS
    Get the type of network connection

.DESCRIPTION
    Retrieve the network connection type when a computer is connected to a domain:
    - LAN
    - Wireless
    - VPN

.EXAMPLE
    Get-NetworkConnectionType

.INPUTS
    none

.OUTPUTS
    One of these string values:
    - LAN
    - Wireless
    - VPN

.NOTES
    version 1.0: initial version
#>

function Get-NetworkConnectionType {
    [CmdletBinding()]
    [OutputType([String])]
    Param ()
    
    begin {
        $connectionType = "n/a"
    }
    
    process {

        # get the connection which is used for domain access
        $connectionProfile = Get-NetConnectionProfile | Where-Object { $_.NetworkCategory -eq "DomainAuthenticated" }

        # if a connection exists, check the adapter in use
        if ($null -ne $connectionProfile) {
            # get the adapter
            $connectionAdapter = Get-NetAdapter -Name $connectionProfile.InterfaceAlias
            switch ($connectionAdapter.PhysicalMediaType ) {
                "802.3" {
                    $connectionType = "LAN"
                    break;
                }
                "Native 802.11" {
                    $connectionType = "Wireless"
                    break;
                }
                "Bluetooth" {
                    $connectionType = "Wireless"
                    break;
                }
                default {
                    $connectionType = "VPN"
                }
            }
        }
        
    }
    
    end {
        Write-Output $connectionType
    }
}

Date de publication:

17/03/2019 - 18:17

Dernière modification:

17/03/2019 - 18:42

Office 365 - Reconfiguration après installation initiale

Roland Danard — Sun, 03 Feb 2019 19:23:52 +0000

Principe

La reconfiguration d'une installation d'Office 365 pour ajouter ou supprimer un composant (Access, Publisher, ...) un produit annexe (Visio, Project, ...), voire une langue d'interface, suppose une réinstallation de la suite, en prenant compte d'une part les ajouts/suppressions demandés, et d'autre part les éléments déjà installés.

Les sources d'Office 365 incluent déjà tous ces éléménts, indépendamment de ce qui a été demandé lors du téléchargement (le paramétrage effectué pour cette opération vise essentiellement à télécharger les composants linguistiques souhaités).

L'approche usuelle est de préparer pour chaque élément à ajouter/supprimer un fichier de configuration, précisant les opérations à effectuer comme lors d'une installation initiale, qui peut alors être appliqué sur le poste de travail.

Le défaut est qu'il est difficile de gérer la multiplicité des cas possibles, en particulier pour les composants d'Office ProPlus : il faut prévoir une configuration pour ajouter Access, une autre pour ajouter Publisher, une autre pour ajouter Publisher mais enlever Access, ...

Cela devient rapidement ingérable, surtout si on y ajoute la gestion des langues !

Et pour ajouter un peu de complexité, plusieurs versions d’Office 365 cohabitent, suivant les canaux de mise à jour choisis, avec parfois plusieurs versions différentes sur un même canal…

Script de reconfiguration

Le script de reconfiguration est là pour simplifier les opérations.

A partir des informations présentes sur la machine (voir l'article consacré à la description des entrées de registre liées à l'installation d'Office ici), un fichier de configuration au format XML est regénéré, correspondant au plus proche à ce qui a été exécuté pour l'installation.

Exemple :

<Configuration>
  <Add OfficeClientEdition="32" Channel="Broad" Version="16.0.10730.20264" >
    <Product ID="VisioStdXVolume">
      <Language ID="fr-fr" FallBack="en-US" />
    </Product>
    <Product ID="O365ProPlusRetail">
      <ExcludeApp ID="onedrive" />
      <ExcludeApp ID="access" />
      <Language ID="fr-fr" FallBack="en-US" />
    </Product>
  </Add>
  <Logging Level="Standard" Path="C:\InstallationLogs\Office365" />
</Configuration>

Cette configuration est alors mise à jour pour tenir compte des ajouts ou suppressions demandés.

Par exemple, pour ajouter Access :

<Configuration>
  <Add OfficeClientEdition="32" Channel="Broad" Version="16.0.10730.20264" >
    <Product ID="VisioStdXVolume">
      <Language ID="fr-fr" FallBack="en-US" />
    </Product>
    <Product ID="O365ProPlusRetail">
      <ExcludeApp ID="onedrive" />
      <Language ID="fr-fr" FallBack="en-US" />
    </Product>
  </Add>
  <Logging Level="Standard" Path="C:\InstallationLogs\Office365" />
</Configuration>

Enfin, comme il s'agit au final de procéder à une réinstallation, la localisation des fichiers est ajoutée.

Par exemple, avec des sources disponibles sur un partage réseau :

<Configuration>
  <Add OfficeClientEdition="32" Channel="Broad" Version="16.0.10730.20264" SourcePath="\\FileServer\Sources\Office365\1808-SA" >
    <Product ID="VisioStdXVolume">
      <Language ID="fr-fr" FallBack="en-US" />
    </Product>
    <Product ID="O365ProPlusRetail">
      <ExcludeApp ID="onedrive" />
      <Language ID="fr-fr" FallBack="en-US" />
    </Product>
  </Add>
  <Logging Level="Standard" Path="C:\InstallationLogs\Office365" />
</Configuration>

Une fois la nouvelle configuration générée, elle est appliquée en utilisant le programme d'installation standard d'Office 365.

Paramètres d'exécution

Les paramètres du script sont les suivants :

liste de composants à ajouter
liste de composants à supprimer
liste de produits à ajouter
liste de produits à supprimer
liste de langues d'interface à ajouter
indicateur de suppression de contrôle de version
localisation du dossier comportant le programme Setup.exe d'Office 365
localisation du dossier comportant les fichiers sources d'Office 365

Composants & Produits

Les composants gérés sont : Access, Excel, Groove, Lync, OneDrive, OneNote, Outlook, PowerPoint, Publisher, Word, Bing.

Les produits gérés sont : ProjectProXVolume, ProjectStdXVolume, ProjectProRetail, ProjectStdRetail, VisioProXVolume, VisioStdXVolume, VisioStdRetail, VisioProRetail,AccessRuntimeRetail.

Ces listes peuvent être étendues pour ajouter de nouveaux produits si nécessaire.

Gestion des langues

Si aucun paramètre spécifique n'est indiqué, les langues déjà présents sur le poste sont reconduites, et la langue par défaut d'Office est conservée.

Dans le cas contraire, les langues à installer doivent être indiquées en précisant leur code (suivant la notification IETF), la première entrée de la liste indiquant alors la langue par défaut d'Office après reconfiguration.

Pour les produits ajoutés, si aucun paramètre de langue n'est précisé, la langue par défaut est alors celle du système d'exploitaiton, avec un repli sur en-US en cas d'indisponibilité.

Dans tous les cas, une langue ne peut être ajoutée que si elle est présente dans les fichiers sources fournis.

Gestion des versions

Le principal problème pouvant survenir lors de la réinstallation d'Office 365 est qu'il est possible de faire un retour arrière sur le niveau de version très facilement, le programme d'installation ne contrôlant pas actuellement ce point.

Lors de la détermination de la configuration installée, le script détermine la version présente.

Par défaut, si la version installée est différente de la version fournie dans les soures, l'installation n'a pas lieu.

Si le drapeau de suppression de contrôle de version est levé, le contrôle de version n'a pas lieu et l'installation se fera avec la version présente dans les sources, permettant alors une montée ou descente de version, suivant le cas.

Programme d'installation d'Office 365

Le programme Setup.exe destiné à l'installation d'Office 365 évolue indépendamment des sources d'Office (nouvelles fonctionnalités, corrections d'erreurs, ...).

Par défaut, le script le recherchera dans le dossier des sources, ou dans le dossier précisé en paramètre.

Si aucun programme n'est trouvé, l'installation ne pourra pas avoir lieu.

Sources d'Office 365

Le paramètre spécifiant la localisation des sources est obligatoire pour procéder à l'installation.

Un contrôle minimal est effectué sur son contenu (présence d'un dossier portant le n° de version d'Office).

Si la localisation n'est pas fournie ou si le contrôle échoue, l'installation ne pourra pas avoir lieu.

Date de publication:

03/02/2019 - 20:23

Dernière modification:

28/01/2020 - 13:30

Gestion des évolutions du poste de travail

Roland Danard — Tue, 25 Feb 2014 12:47:56 +0000

1. Aperçu

Les différents éléments du poste de travail, que ce soit le système d’exploitation, les pilotes de périphériques, les divers outils installés ou les composants bureautique, vont connaître lors de la vie du poste des corrections et des évolutions.

La gestion des mises à jour des composants du poste de travail recouvre deux cas différents :

les mises à jour qui n'ont pas d'impact sur les applications métier
les mises à jour qui peuvent avoir des impacts sur les applications métier

Le premier cas couvre usuellement les mises à jour du système d'exploitation, les mises à jour mineures des composants de base, du socle applicatif système et des composants du socle bureautique.

Le second cas couvre les mises à jour majeures du système d'exploitation (services packs et assimilés), et les mises à jour majeures des autres composants.

Dans certains cas, comme celui du runtime Java, toute mise à jour peut (aura) un impact sur les applications métier.

Il est donc difficile voire impossible d'automatiser totalement le déploiement des mises à jour, et chaque mise à jour doit être examinée avant son déploiement dans l'environnement de production.

La méthode d'implémentation des mises à jour diffère de plus suivant la couche impactée. Elles peuvent être mises en place :

par mise à jour du composant "sur place"
par désinstallation de la version précédente avant installation de la nouvelle
par ajout d'un nouveau composant
par ajout d'une nouvelle version de composant cohabitant avec les versions précédentes
par suppression d'un composant
par suppression d'une version spécifique d'un composant

Dans le cas des images de poste de travail, la situation est un peu différente. A moins de devoir faire évoluer un composant inclus dans la version de base du système d'exploitation fournie par l'éditeur, il ne devrait y avoir que des installations pures, jamais de mise à jour ou suppression.

2. Socle Système d’Exploitation

2.1 Système d’exploitation

On ne considère ici que les mises à jour majeures telles que les Service Pack, les mises à jour autres étant prises en compte dans les chapitres sur les mises à jour système.

Ce type de mise à jour implique généralement de reprendre totalement l’image poste de travail.

2.2 Composants systèmes de base

Dans le cas des composants Microsoft (bibliothèques .Net, C/C++, …) la mise à jour se fait dans le même processus que les mises à jour du système.

On prendra donc en compte ici essentiellement le cas de composants non mis à jour par les mécanismes liés au système d’exploitation, ou le cas de l’ajout de nouvelles versions de ces composants.

2.3 Mises à jour système – sécurité

On ne prend ici en compte que les mises à jours liés au système d'exploitation proprement dit, même si le mécanisme de mise à jour du système prend en compte d'autres composants (comme dans le cas des systèmes Microsoft la mise à jour de MS Office).

Pour Windows, les mises à jour sont fournies tous les mois, avec la possibiltié d'avoir des mises à jour de sécurité critiques hors cycle usuel.

Lors de la fourniture d'un nouveau lot de mises à jour, leur contenu doit être évalué afin de vérifier si ces mises à jours sont pertinentes par rapport au poste de travail considéré, et les impacts à anticiper.

2.4 Mises à jour système – fonctionnelles

Tout comme pour les mises à jour de sécurité, on ne considère ici que les mises à jour concernant le système d'exploitation.

La principale différence avec les mises à jour de sécurité est que ces mises à jour fonctionnelles ne sont pas obligatoires et sont mises à disposition pour corriger des problèmes spécifiques.

La règle de base est donc de ne les installer que dans les cas où le problème résolu par la mise à jour est avéré.

Par ailleurs, il est fréquent que ces mises à jours fonctionnelles se retrouvent incorporées dans une mise à jour de sécurité ultérieure, ou dans une mise à jour fonctionnelle plus globale.

Dans ce dernier cas, la difficulté sera, en cas de dysfonctionnement, d'identifier précisément quelle partie de la mise à jour pose problème.

2.5 Pilotes de périphériques

La mis à jour de pilotes sur un poste existant ne devrait avoir lieu que lorsqu'il n'existe pas d'alternative et que la mise à jour est requise pour corriger un problème connu, comme dans le cas des mises à jour fonctionnelles du système d'exploitation.

La règle d'or est : "si ce n'est pas cassé, pourquoi réparer ?"

L'impact de la mise à jour d'un pilote de périphérique sur un poste existant peut être important, surtout s'il s'agit de pilotes relatifs aux composants réseau, car l'échec de la mise à jour peut résulter en un poste de travail non accessible par les outils de gestion à distance.

Dans le cas des pilotes inclus dans l'image du poste de travail, la situation est différente.

L'ajout se fera principalement pour la prise en compte de nouveaux modèles de postes de travail.

Dans le cas où un nouveau modèle de poste comporte des composants pour lesquels les pilotes sont communs avec les modèles précédents, il peut être envisagé de les mettre à jour si une version plus récente est disponible.

A noter que dans certains cas les pilotes peuvent avoir des pre-requis qui devront être inclus dans l'une des collections de composants du socle "Système d'Exploitation". Suivant l'ordre d'installation à respecter, cela peut mener à une nouvelle version de l'image du poste de travail.

3. Socle applicatif système

3.1 Aperçu

Les mises à jour d'application appartenant à cette couche doivent être rares.

Les déclencheurs d'actions seront principalement des problèmes de sécurité, des problèmes liés à la mise à jour du socle "Système d'Exploitation", ou l'ajout de nouvelles fonctionnalités ou de nouveaux outils.

3.2 Précautions à prendre

3.2.1 Composants liés à la sécurité

La mise à jour de ce type de composants doit être abordée avec les plus extrèmes précautions.

Il peut y avoir des interactions non anticipées entre certains composants de cette couche, comme par exemple l'antivirus et le parefeu : par exemple, le parefeu peut être configuré de telle sorte de bloquer l'accès au réseau si aucun antivirus n'est présent ou que ses définitions sont obsolètes ; cela posera alors un problème lors d'un changement de version de l'antivirus si celui ci implique la désinstallation de la version précédente, ou l'installation d'une version packagée avec des définition virales un peu trop anciennes : le parefeu bloquera tout d'abord l'accès au réseau suite à l'absence d'antivirus, puis suite à l'ancienneté de la configuration ...

3.2.2 Bibliothèques et runtimes

Certains composants de cette couche sont requis pour faire fonctionner des applications de plus haut niveau appartenant au socle bureautique ou pour les applications métier, comme par exemple c'est le cas pour le runtime Java.

Les mises à jour pour ces composants peuvent inclure des modifications qui vont avoir un impact négatif sur les applications qui les utilisent (ex : changement de règles de sécurité pour Java).

Il est donc vital de ne pas inclure ces nouvelles versions dans l'image du poste de travail tant qu'il n'a pas été vérifié et validé par ailleurs qu'elles ne posent pas de problèmes, après avoir procédé à la mise à jour sur le parc existant.

4. Socle Bureautique

4.1 Aperçu

Les composants de cette couche sont mis à jour de la même façon que pour les couches inférieurs, avec des mises à jour de sécurité et des mises à jour fonctionnelles.

4.2 Précautions à prendre

Les outils bureautique sont susceptibles d'être mis à jour de façon périodique par changement de version majeure.

L'impact sera plus ou moins important selon qu'il s'agit d'un visualiseur de fichiers ou de la suite bureautique principale.

Tout comme les mises à jour du socle applicatif système, l'inclusion dans l'image du poste de travail ne doit avoir lieu qu'une fois la mise à jour validée sur le parc existant, et qu'aucun impact n'a été constaté ou que les impacts ont été pris en compte.

Date de publication:

25/02/2014 - 13:47

Dernière modification:

10/02/2015 - 13:10

Gestion des versions de poste de travail

Roland Danard — Tue, 25 Feb 2014 12:15:09 +0000

1. Objectif

La définition d’un numéro de version permet d’identifier facilement les composants principaux présent sur un poste de travail, afin de faciliter les opérations de support et de mise à jour.

2. Contraintes

La problématique d’identification du contenu nécessite de bien délimiter les différentes sections du socle.

Il faut de plus définir les évènements qui vont conduire à faire évoluer la version ; on distinguera principalement les modifications mineures et les modifications majeures ; il est aussi intéressant, surtout pour Windows, de connaître le niveau des mises à jour de sécurité incluses.

3. Remarques

Les niveaux de modification majeures et mineures peuvent s’apprécier en fonction de l’évolution des composants inclus dans le master ; un changement de version majeure de l’un de ces composants entraine la modification du numéro de version à un niveau plus important qu’un changement mineur, par exemple.

L’un des derniers aspects à prendre en compte est l’évolution du poste ; il est souvent utile de savoir, en plus de la version courante du master installé sur un poste, dans quelle version le poste a été installé initialement et comment il a été mis à jour au fil du temps.

4. Propositions

4.1 Schéma 1

Les mises à jour sont effectuées de façon périodique, les différentes briques étant mises à jour simultanément.

Le numéro de version d’un poste se présente sous la forme A.B.C.D, où :

A : identifie le système d’exploitation
B : identifie la version majeure
C : identifie la version mineure
D : identifie le niveau de mise à jour

Par exemple :

A : W7 = Windows 7
B : 1 = première version du master
C : 2 = 2^ème mise à jour mineure
D : 1312 = inclusion des mises à jour jusqu’en décembre 2013

Soit : W7.1.2.1312

4.2 Schéma 2

Ce schéma permet d’identifier de façon individuelles les évolutions de chaque brique du socle.

Le numéro de version d’un poste se présente sous la forme A.B.C.D.E, où :

A : identifie le système d’exploitation
B : identifie la version du socle système d’exploitation
C : identifie la version du socle applicatif système
D : identifie la version du socle bureautique
E : identifie le niveau de mise à jour

Par exemple :

A : W7 = Windows 7
B : 4 = 4^ème version du socle système d’exploitation
C : 7 = 7^ème version du socle applicatif système
D : 1 = 1^ère version du socle applicatif bureautique
E : 1401 = inclusion des mises à jour jusqu’en janvier 2014

Soit : W7.4.7.1.1401

Remarque : l’ordre exact de prise en compte des briques peut être adapté suivant la fréquence de mise à jour de chaque élément.

Date de publication:

25/02/2014 - 13:15

Dernière modification:

09/02/2015 - 23:05

Organisation d'un socle Poste de Travail

Roland Danard — Tue, 07 May 2013 10:40:45 +0000

1. Généralités

Ce document précise comment s'organise un poste de travail informatique, depuis les couches basses (système d'exploitation) jusqu'aux applications destinées à l'utilisateur final.

2. Schéma de principe

Le poste de travail se compose de plusieurs couches imbriquées, comme indiqué ci-dessous:

On ne prend pas en compte dans ce schéma les couches supplémentaires qu’il faudrait définir en fonction des besoins « métier ».

3. Socle Système d'exploitation

3.1 Système d'exploitation

Il s'agit de la version de base du système d'exploitation, telle que fournie par l'éditeur, avant toute application de mises à jour.

Dans le cas de Windows, il pourra s'agir d'une version du système incluant un Service Pack.

3.2 Composants systèmes de base

On retrouve ici des composants qui ne font pas partie directement du système d’exploitation, et qui constituent des pre-requis à d’autres composants.

Sous Windows on retrouve en particulier les diverses version des bibliothèques .Net, les bibliothèques C/C++, …

3.3 Pilotes de périphériques

On trouve ici tous les pilotes de périphériques spécifiques qui doivent être présents sur les postes.

Usuellement, les pilotes fournis avec le système d'exploitation peuvent être suffisants, mais pour certains composants additionnels un pilote spécifique peut être requis.

3.4 Mises à jour du système

Les mises à jour système englobent les mises à jour de sécurité liées au système d’exploitation et aux composants de base, ainsi que les mises à jour fonctionnelles éventuelles.

3.5 Configuration utilisateur initiale

La configuration utilisateur initiale correspond aux éléments de paramétrage qui doivent être appliqués à l’utilisateur lors de sa première connexion, sans prendre en compte les modifications qui doivent être appliqués ultérieurement.

4. Socle Applicatif Système

4.1 Outils de sécurité

On retrouve ici l’antivirus, le pare-feu, les gestionnaires de carte à puce, …

4.2 Outils systèmes

On retrouve ici les outils additionnels destinés à la gestion du poste de travail, par exemple ceux destinés à la connexion aux services d’infrastructure, aux équipes de support …

Outils de connexion

Il s’agit plus spécifiquement des outils destinés aux ordinateurs portables afin d’assurer la connexion sécurisée au réseau de l’entreprise (VPN, outils d’aide à la connexion sur réseaux non filaires, …).

4.3 Autres éléments système communs

On retrouve ici tous les autres utilitaires qui ne rentrent pas dans l’une des catégories ci-dessus.

5. Socle Bureautique

5.1 Visualiseurs de fichiers

On retrouve ici tous les utilitaires permettant de consulter certains types de fichier, en particulier tous les types de fichiers qui ne sont pas pris en compte par la suite bureautique standard, comme par exemple un lecteur de fichier PDF.

5.2 Suite bureautique

On retrouve ici traitement de texte, tableur, …

5.3 Autres éléments

On retrouve ici tous les autres logiciels qui ne rentrent pas dans l’une des catégories ci-dessus.

Date de publication:

07/05/2013 - 12:40

Dernière modification:

09/02/2015 - 23:05

danard.net - Poste de travail

Systray Info: information sur votre ordinateur

Date de publication:

Dernière modification:

Tags:

Interface d'administration

Date de publication:

Dernière modification:

Tags:

Réseau - Détection du type de connexion

Date de publication:

Dernière modification:

Tags:

Office 365 - Reconfiguration après installation initiale

Principe

Script de reconfiguration

Paramètres d'exécution

Composants & Produits

Gestion des langues

Gestion des versions

Programme d'installation d'Office 365

Sources d'Office 365

Date de publication:

Dernière modification:

Tags:

Gestion des évolutions du poste de travail

1. Aperçu

2. Socle Système d’Exploitation

2.1 Système d’exploitation

2.2 Composants systèmes de base

2.3 Mises à jour système – sécurité

2.4 Mises à jour système – fonctionnelles

2.5 Pilotes de périphériques

3. Socle applicatif système

3.1 Aperçu

3.2 Précautions à prendre

3.2.1 Composants liés à la sécurité

3.2.2 Bibliothèques et runtimes

4. Socle Bureautique

4.1 Aperçu

4.2 Précautions à prendre

Date de publication:

Dernière modification:

Tags:

Gestion des versions de poste de travail

1. Objectif

2. Contraintes

3. Remarques

4. Propositions

4.1 Schéma 1

4.2 Schéma 2

Date de publication:

Dernière modification:

Tags:

Organisation d'un socle Poste de Travail

1. Généralités

2. Schéma de principe

3. Socle Système d'exploitation

3.1 Système d'exploitation

3.2 Composants systèmes de base

3.3 Pilotes de périphériques

3.4 Mises à jour du système

3.5 Configuration utilisateur initiale

4. Socle Applicatif Système

4.1 Outils de sécurité

4.2 Outils systèmes

Outils de connexion

4.3 Autres éléments système communs

5. Socle Bureautique

5.1 Visualiseurs de fichiers

5.2 Suite bureautique

5.3 Autres éléments

Date de publication:

Dernière modification:

Tags: