Archive

Posts Tagged ‘IIS’

SCCM – Troubleshooting avancé et la boule de Cristal

sccm2012Bonjour à tous,

Je fais ce post, vite fait pour vous relater un problème que j’ai rencontré avec ConfigMgr 2007 (SCCM). Et notamment, avec le rôle Management Point versus PXE. Nous avons un serveur Central SCCM (hébergeant aussi la base SQL) et un serveur dédié pour les rôles de PXE, Distribution Point et State Migration Point.

Quant au Central, celui-ci possède les rôles habituels, et notamment le rôle de Management Point.

CONTEXTE/ISSUE
Nous avions déplacé temporairement, le rôle Management Point sur le serveur dédié (PXE, etc.), dans le but de corriger un problème IIS sur le serveur d’origine (Central). Et notamment, concernant la configuration de BITS sur le répertoire CCM_Incoming (Error 500 httpSendRequest)…

Au passage, je vous donne la procédure pour réinstaller Microsoft IIS sur SCCM :

http://blogs.technet.com/b/configurationmgr/archive/2009/08/12/configmgr-2007-how-to-properly-reinstall-iis-in-windows-server-2008-on-an-sccm-2007-site-system.aspx

Là, aucun problème, tous les services SCCM raccrochent les informations, et considèrent correctement le nouveau serveur Management Point comme acquis et fonctionnel sur le serveur dédié (PXE, etc.)

Une fois le problème IIS corrigé sur le serveur, nous avons, bien sûr voulu rebasculer le rôle MP sur son serveur d’origine. Et là problème ! Ce qui s’était bien passé la 1ère fois sur le serveur temporaire, s’est mal passé la deuxième fois (Apparemment), lorsque nous avons remis le rôle à sa place. nous nous sommes pas aperçu tout de suite :

La particularité de ce problème, c’est qu’une fois le rôle MP réinstallé sur le serveur d’origine (Central), le fichier de LOG : MPControl.log fait un Code Retour 200 OK dans son autocheck httpSendRequest !! Si on consulte les fichiers de LOG IIS, même chose ! Code Retour 200 !

Malgré tout impossible de déployer une Task Sequence de déploiement de Windows Seven !!

ANALYSES
Après avoir consulté le fichier Log : MPSetup.log, je ne vois aucune erreur, hormis l’installation du fichier MSI. Erreur que j’avais résolu par une réinstallation du rôle MP, pour corrigé le problème. Ceci avait d’ailleurs fonctionné, raison d’ailleurs pour laquelle je n’avais aucune erreur dans le fichier de Log : MPSetupl.log qui se terminait bien par : Installation Successfully.

Mais malgré tout, le rôle Management Point ne fonctionnait plus, et ceci malgré ce que pouvaient dire les fichiers de Logs d’IIS de SCCM (MPControl.log), etc. Je ne parle pas de la console qui reste muette sur le sujet … “Tout est vert, il fait beau, 25 degrés à l’ombre, bref ! Rien à signaler !

Donc je décide d’investiguer côté poste de travail : Le symptôme sur les postes de travail était le suivant : Les postes démarrent bien en mode PXE, chargent bien l’image de démarrage WINPE, mais redémarrent brusquement au bout de 60 secondes, voir moins (Et ceci malgré une console DOS (F8) ouverte). Malgré tout, nous arrivons a récupérer le fichier Log : SMSTS.Log et là l’erreur fait son apparition : No MP Certificates

Une rapide analyse m’envoie vers le fichier de Log : SMSPXE.log. Dans celui-ci, je vois que le serveur Management Point, ainsi que la clé de sécurité (le fameux Certificat) ne sont plus renseignés :

Loaded PXE settings from DB: Default MP: <empty>, Public Certificates: <empty>

ACTIONS DE CORRECTIONS
1 – Je décide donc, de redémarrer le service PXE Service Point (WDS) sur le serveur, afin de forcer le rôle PXE à lire dans la base, les informations concernant le Management Point, afin qu’il met à jour la nouvelle condition du dit rôle ! Rien à faire. Les données ne sont toujours pas renseignées !

2 – Je décide donc d’installer le Rôle PXE (Moins impactant que le rôle MP, sachant qu’on est en production). Même chose ! Aucun effet ! Les données restent vides ! Les services sont inopérants !

Donc par déduction, le problème, vient à coup sûr du Management Point ! De plus, entre-temps, on m’annonce que toutes les télédistributions d’applications sont arrêtées. Les clients n’ont plus accès aux publications !! Bonjour la pression ! Bref ! Quoi qu’il en soit, cela me conforte dans l’idée que le problème vient bien du Management Point sur le Central. Je décide donc de désinstaller celui-ci du serveur Central.

Mais avant… Une rapide recherche chez Microsoft, pour savoir si le problème est référencé ! Et je retrouve la KB et la procédure que j’avais faite pour corriger le problème d’installation du MSI : http://support.microsoft.com/kb/2419559/fr-fr

[… As of right now, the easiest way to resolve this issue is to remove and reinstall the BITS component. If the ConfigMgr 2007 Management Point role was already installed then it will also be necessary to remove and reinstall that role once you’ve done the same with BITS…]

3 – Je ré-applique donc la procédure, malgré que mon installation MP.MSI se soit bien passée la 1ère fois et que du point de vue de SCCM, le rôle Management actuel, fonctionne !

Sans surprise, la procédure se passe correctement, le Management Point revient en [Status 200 OK] dans MPControl.log, idem dans les fichiers de Logs de Microsoft IIS du Central… Le tout est de savoir ce que fait le PXE derrière ! Bah il fonctionne !!! Les champs sont renseignés. Je retrouve le nom FQDN de mon Management Point, ainsi que sa clé de Sécurité (Certificat).

Loaded PXE settings from DB: Default MP: SERVER.EVENT-HORIZON.FR, Public Certificates: 308201E63082014FA00302010202109326C3F7A4B9D2934497E…

Je repousse les boot images sur le serveur PXE (En conséquence de mes premières actions concernant PXE). Tout redevient comme avant ! Le déploiement OSD fonctionne à nouveau, ainsi que les publications d’applications !

Je voulais partager cette expérience avec vous, car cela vous donne un exemple de troubleshooting dans SCCM, dans lequel il n’est pas toujours évident de diagnostiquer un problème quand les logs ne reflètent par l’état réel des services SCCM, Et c’est encore moins facile quand la console SCCM reste muette comme un carpe !

Pour finir, dans l’histoire, je ne suis pas sûr que le réel problème vienne de Microsoft IIS. Je pense à quelque chose de plus profond, lié au socle et à un manque de stabilité du serveur. Je pense que le problème de Microsoft IIS n’est qu’un symptôme. Problème qui nous a d’ailleurs obligé à réinstaller IIS dès le début de l’incident ; Que part effet domino, le reste à suivi, provoquant le bug… Bienvenu dans le monde SCCM ! 🙂

Enjoy !

Michel PICOLLET | EXAKIS Paris
Solution Architect Microsoft [System Center]
mpicollet@event-horizon.fr

SCCM – Quand installer un site secondaire et qu’est-ce qu’implique une telle installation… ?

Un peu de théorie…

Bonjour à tous,

Sans vouloir enfoncer des portes ouvertes, voici un petit post vite fait sur l’installation d’un site secondaire SCCM. Pour ceux qui se pose encore la question… Quand installer un site secondaire et qu’est-ce qu’implique une telle installation… ? Entre-autres choses –> Non exhaustif !

logo-sccm-2007

Hiérarchie SCCM

image_2Déjà première règle, l’installation d’un site secondaire est d’abord et avant tout fait pour contrôler le débit d’une liaison WAN entre le dit site secondaire et le site primaire, dont il dépend.

On peut dire en vulgarisant un peu qu’un site secondaire SCCM est une sorte de « relais » entre les clients d’un site distants et le site primaire SCCM.

En effet, les clients communiqueront avec l’infrastructure SCCM par le biais du site secondaire SCCM installé et disponible localement. Si on pense « relais », il est facile de comprendre que ces clients SCCM ne sont pas réellement assignés et gérés par le site secondaire, mais en réalité par le site primaire SCCM. Le site secondaire n’étant qu’un intermédiaire afin de préserver la bande passante…

NOTE 1 : Pour exemple, l’item Client Agents n’existe pas pour les sites secondaires…

NOTE 2 : Dans la console, il se peut que vous voyiez des clients "assignés" à un site secondaire. Ceci n’est qu’une vue pour des postes tout juste découverts, mais ne possédant pas encore d’agent SCCM. Une fois l’installation faite de celui-ci, les postes seront bien assignés par le site primaire du dessus.

Autre point, sur le plan hiérarchique, un site secondaire ne peut pas lui-même possèder un site SCCM enfant (Primaire ou secondaire). Un site secondaire est donc obligatoirement le dernier niveau de site d’une hiérarchie. Seul un site primaire SCCM peut possèder un site secondaire enfant… Un site primaire peut aussi avoir un autre site primaire enfant en dessous de lui … Exemple d’architecture avec 1 primaire et 3 secondaires SCCM …

clip_image002

NOTE : Il faut savoir que la licence SCCM Secondary est gratuite ! Car celle-ci était ignorée par les entreprises de part son coût dans les versions précédentes (SMS). Microsoft a donc décidé de vous faciliter les choses.


Base SQL pour les sites secondaires SCCM

Aucune !! La seule base qui pourrait y avoir sur un site secondaire serait apportée par Microsoft WSUS (SQL Express) dans le cadre de l’activation de Software Update Point dans SCCM.

Par contre, lorsque vous activez certain rôle, comme le (Proxy) Management Point, le compte machine (NetBIOS Name) du serveur secondaire SCCM doit avoir des droits assez forts (voir SysAdmin), sur la base de données du site primaire parent auquel il dépend. En effet, celui-ci (Serveur Secondaire) doit pouvoir “cocher” le rôle SMSDBROLE_MP pour la base SCCM en vigueur. (Fig.1)

image


Gestion de la bande passante avec SCCM

Il est possible donc de gérer la bande passante avec SCCM de lors que l’on dispose d’un site SCCM “enfant”, primaire ou secondaire, en dessus du site central (primaire). Cette bande passante est entre “les mains” du “Sender” (en fait Address), que vous configurez dans la console SCCM.

En effet, lorsque vous installez un site secondaire et que vous créez du même coup l’adresse afin que les deux sites puissent communiquer, vous avez la possibilité de décider du mode de réplication (% de bande passante, Calendriers, etc.) et la plage horaire, à utiliser (Fig.2 et 3). Mais aussi les priorités des objets et leur mode de réplication (Fig.2)

image image

Limites de site SCCM

Les limites de site SCCM définissent le périmètre que doit gérer “physiquement” un site SCCM (Primaire ou secondaire). Lorsque vous attribuez une limite de site SCCM à un site, c’est une façon de “dire” au site en question, le périmètre IP (mais aussi AD, Subnet, etc.) qui gérera.

Pour un site secondaire, il “saura” alors que les postes qui seront dans son périmètre ne lui seront pas directement assignés, mais qu’il servira uniquement d’intermédiaire entre les postes et son site SCCM primaire parent.

Il faut savoir que toutes les limites de site de chaque site enfant remontent à travers la hiérarchie SCCM. En traduction, le site central (Primaire) SCCM (Le Site le plus haut), “possède” toutes les limites de sites SCCM de hiérarchie. Elle apparaissent toutes dans l’item Boundaries du site central.

Voir aussi la notion de Protected DP dans SCCM
http://technet.microsoft.com/en-us/library/bb892788.aspx


Pré requis pour installer un site secondaire SCCM

Les prérequis SCCM pour un site secondaire, sont quasiment les mêmes que pour un site primaire. A ceci près que Microsoft SQL ne doit pas être installé. Les prérequis sont Microsoft IIS, WebDAV, etc.


Backup d’un site SCCM Secondaire

Oubliez !! Même si c’est possible, il est plus facile de reconstruire de zéro le site secondaire, que de le restaurer. Dans ce cas, pour restaurer les packages, voir  l’outil Microsoft Preload Package On Site. (Explication de l’outil ici)


Console SCCM

Il n’existe aucune console pour gérer directement un site secondaire SCCM. En effet, le rôle SMS Providers n’est pas présent sur un site secondaire. Normal, celui-ci ne possédant d’aucune base de données SQL … Vous devrez donc administrer le site secondaire en utilisant la console du primaire SCCM auquel il dépend. Dans ce cas, la console du primaire utilise le rôle SMS Providers de son primaire…


Quand décider de mettre un site Secondaire ou un site primaire, voir un Branch DP ?

Pour faire simple… Et entre-autres choses, comme la criticité de la population cible, etc!

On met un site primaire pour d’abord déléguer l’administration du dit site SCCM à une équipe locale, alléger les liaisons WAN dans une topologie hiérarchique SCCM, supporter une charge et un nombre de machines conséquent dans le dit site (entre 1000 et 2000 environ on peut se poser la question) et rendre le site “autonome”… surtout en cas de problèmes potentiels (Pour entités spéciales, VIP, etc.)

On met un site secondaire SCCM pour alléger les liaisons WAN dans une topologie hiérarchique SCCM, supporter un nombre de machines moindre dans le dit site (Mais entre 100 et 1000 environ) et rendre le site “autonome” mais non modifiable (packages, objets collection, WIM, etc.), car console inopérante, en cas de besoin ou de problèmes potentiels.

On met un Branch Distribution Point (ou BDP) SCCM, avec tolérance de panne pour alléger les liaisons WAN lors de la récupération des packages SCCM, supporter un petit nombre de machines (entre environ~25 et 100) sans être obligé d’installer une machine OS server pour y mettre un secondaire. En effet, un poste de travail suffit ! Celui-ci permet de mettre à disposition l’ensemble des packages SCCM pour les postes de son site. Par contre, un BDP ne peut pas récupérer les inventaires des postes. Celui-ci ne sert que pour la récupération des packages.

On met un Branch Distribution Point (ou BDP) SCCM pour alléger les liaisons WAN lors de la récupération des packages SCCM, supporter un petit nombre de machines (entre 3 et 25 environ) sans être obligé d’installer une machine OS server pour y mettre un secondaire. En effet, un poste de travail suffit ! Celui-ci permet de mettre à disposition l’ensemble des packages SCCM pour les postes de son site. Par contre, un BDP ne peut pas récupérer les inventaires des postes. Celui-ci ne sert que pour la récupération des packages.

How to Deploy a Branch Distribution Point
http://technet.microsoft.com/en-us/library/bb632651.aspx


Diagramme – Vecteurs de décisions

Vecteurs de décisions

Enjoy !

Michel PICOLLET | EXAKIS Paris
Consultant Senior Microsoft [System Center]
mpicollet@event-horizon.emea.microsoftonline.com

SCCM – Script PowerShell d’installation automatisée de toute la solution Microsoft pour Microsoft SCCM 2007 SPx Rx (Rôles Serveur, IIS (Webdav, etc.) SQL 2008, WSUS, SCCM (primaire ou Secondaire))

logo-sccm-2007

Bonjour à tous,

Voici la version « définitive » du script d’automatisation des installations pour SCCM (ou autres)… Englobant l’installation automatique des rôles et fonctions serveurs (R2 ou non) de Microsoft SQL 2008 server (R2 ou non), de WSUS 3.0 SP2 en normal ou en NLB, et enfin de SCCM 2007 SPx Rx

De plus, celui-ci permet de préparer l’environnement de Hydration, création des répertoires qui accueilleront les sources de chaque solutions susnommées. Et celui-ci, avec les arguments –DiskConfig et –Ipconfig permettra respectivement de configurer le disque des installations (où seront installées chaque solutions (SQL, SCCM, etc.) et la carte réseau (Adresse IP, Gateway, DNS, etc.).

Utilisation d’un fichier CSV

La particularité de cette version réside dans l’utilisation d’un fichier CSV que vous devez au préalable renseigner afin de correspondre avec votre environnement cible. Donc plus besoin de modifier le script pour renseigner les infos nécessaires comme avant…

Petite précision, tout ce que vous renseignez dans le fichier CSV est créé à la volée… (Répertoires source, cibles, fichiers de réponse d’installation, etc.)

Si je prends l’exemple de l’installation de Microsoft SCCM (i-hydration-v8.0.ps1 -pconfigmgr), le répertoire cible que vous avez spécifié dans le CSV (où vous avez décidé d’installer SCCM) est automatiquement créé ! (En l’occurrence ici, E:\Apps\MSSCCM dans le screenshot suivant…)

Il faut savoir que pour SQL 2008 Rx ou non, la création des répertoires d’installation sont créés par l’assistant (setup.exe) lui-même. Donc le script n’a pas besoin de le faire… (.\i-hydration-v8.0.ps1 –sqlsrv[R2])

clip_image002

Test des environnements

De plus dans cette version, des contrôles sont faits afin d’éviter des accidents ou des maladresses, exemple pour une même instance SQL :

clip_image004

Idem pour le Switch –DiskConfig qui réinitialise le disque dur d’accueil où seront installées vos applications…

clip_image006

Préparation de l’environnement

Pour la préparation de l’environnement Hydration afin d’organiser le déploiement, il suffit de passer la commande : i-hydration-v8.0.ps1 –prepsrv

Cette commande créera les répertoires d’accueil dans lesquels seront ensuite copier par vos soins les sources (binaires) de vos applications (SCCM, SQL, etc.). Le CSV par défaut, pointe sur ces répertoires, mais rien ne vous empêches de pointer sur d’autres répertoires ou même lecteur DVD ou CD

clip_image008

Aide sur l’utilisation du script

Pour finir, je vous invite comme toujours à passer la commande
i-hydration-v8.0.ps1 –help, afin de prendre connaissance des fonctions que l’on peut utiliser avec ce script

De plus, avec –help, le script mappe le fichier .CSV et vous montres les variables qui seront utilisées par le script.

Partie haute : Utilisation du script
Partie centrale : Les cmds construites à la volée, qui seront utilisées par le script
Partie basse : Les variables qui sont actuellement en vigueurs pour le script

image

Je vous conseille bien sûr de tester le script dans un environnement non sensible, afin de vous l’approprier et de détecter qu’il est bien en adéquation avec vos besoins. Petite précision, l’installation de SQL prend déjà en compte les prérequis pour Microsoft forefront… Mais pour se faire, ne pas utiliser d’instance nommée SQL (Seule l’instance par défaut est utilisable)

64pxwindows-powershell-icon Téléchargement du script

Enjoy !

Michel PICOLLET | EXAKIS Paris
Consultant Senior Microsoft [System Center]
mpicollet@event-horizon.emea.microsoftonline.com

WSUS – Script PowerShell d’installation automatisée de Microsoft WSUS 3.0 SPX pour Microsoft SCCM (ou Standalone)

février 25, 2011 5 commentaires

images

Bonjour à tous,
Voici pour ceux qu’ils veulent gagner du temps sur les temps d’installations, un script PowerShell qui installe Microsoft WSUS 3.0 spx de manière automatique.
Dans cette « livraison », se trouve le reportviewer.exe (2008) dont aurait besoin Microsoft WSUS 3.0 (dans .\Sources\WSUS). Le script l’installera de manière automatique, si celui-ci est présent dans le répertoire source…

Utilisation du script

Trois façons d’utiliser le script…
Usage du script -> .\inst-wsus-vx.x.ps1 [arg..]

.\i-mswsus-vx.x.ps1 -wsusOsql :
Installation de WSUS avec l’utilisation de Microsoft SQL [Node1]

.\i-mswsus-vx.x.ps1 -wsusOnlb :
Installation de WSUS en NLB avec l’utilisation de Microsoft SQL [Node2]

.\i-mswsus-vx.x.ps1 -wsusOsqlexpr :
Installation de WSUS avec l’utilisation de Microsoft SQL Express

.\i-mswsus-vx.x.ps1 -iisforwsus :
Installation de Microsoft IIS 7.0 pour Microsoft WSUS 3.0 spx

Pour l’usage du script, utiliser la commande suivante pour avoir l’aide :
.\i-mswsus-vx.x.ps1 –help

clip_image003

Configuration en NLB

Pour la commande : .\i-mswsus-vx.x.ps1 –wsusOnlb

Installer WSUS en cluster NLB

1. Installer Microsoft SQL sur un serveur dédié [par ex. Server1]

2. Passer la commande : .\i-mswsus-vx.x.ps1 –wsusOsql
pour installer WSUS sur votre autre serveur dédié WSUS [1er nœud NLB] [par ex. Server2]

3. Passer la commande : .\i-mswsus-vx.x.ps1 –wsusOnlb
pour installer WSUS (sans base SQL) sur un autre serveur [2ème nœud NLB] [par ex. Server3]

4. [Server1] – Configurer le répertoire virtuel Content dans Microsoft IIS, afin de pointer sur le partage DFS (ou autre)

5. [Server1] – Passer la commande : %ProgramFiles%\Update Service\Tools\wsusutil.exe MoveContent \\[DFS]Server\ShareName Log

6. etc.

Ceci n’est le sujet du présent mail, mai toute la procédure est là : http://technet.microsoft.com/en-us/library/cc708533(WS.10).aspx

NOTE : Vous devez créer un partage qui sera accessible par tous les serveurs WSUS frontaux. Même si vous ne stocker pas les mises à jour en local vous aurez besoin d’un emplacement pour les fichiers de type DFS : Distributed File System (ou autre). Cependant, il n’est pas nécessaire de mettre en place un partage DFS avec un cluster NLB, il est possible d’utiliser un partage classique et d’assurer une tolérance de panne à l’aide de la technologie RAID.

Microsoft IIS

Pour la commande : .\i-mswsus-vx.x.ps1 –iisforwsus

Le script PowerShell génère de manière automatique, à la volée le fichier XML de réponse qui sera dans la foulé utilisé avec le Switch –IISforWSUS pour l’installation des rôles serveur et notamment de Microsoft IIS 7.0

Autre fichiers de réponse

Le script s’appuie sur un fichier de réponse CSV que vous devez remplir ou modifier avant de lancer le script (représentant le contexte de votre environnement)

clip_image004

64pxwindows-powershell-icon Lien du script PowerShell

Enjoy !

Michel PICOLLET | EXAKIS Paris
Consultant Senior Microsoft [System Center]
mpicollet@event-horizon.emea.microsoftonline.com

Catégories :SCCM Étiquettes : , , , , ,

SCCM – Le téléchargement de packages depuis les clients SCCM, possédant plusieurs fichiers ou dossiers, est trop long ou semble être blocké !

logo-sccm-2007

Lorsque vous utilisez Microsoft SCCM 2007 installé sur un socle Microsoft Windows Server 2008 R2 utilisant la version 7.5 de  WebDAV, il est possible que les clients rencontrent des problèmes de téléchargement de packages SCCM depuis le point de distribution, s’ils utilisent le protocole BITS pour se faire…

En effet, le téléchargement sur le client SCCM semble être bloqué ou est interminable lorsque le package contient de nombreux dossiers et les fichiers… Il s’agit en fait d’un problème connu dans 7.x WebDAV qui a été résolu par un correctif dans la version non-R2 de Windows Server 2008. Il semble donc que cette question soit la même que celle décrite dans le KB957001


KB957001 – A hotfix rollup is available for the out-of-band WebDAV module for IIS 7.0 :
http://support.microsoft.com/default.aspx?scid=kb;EN-US;957001

Mais pour la version 7.5 de IIS, le correctif n’était pas applicable, car il s’agissait d’une version plus ancienne que celle qui est déjà présent dans la version de Microsoft Windows Server 2008 R2. Après en avoir discuté avec l’équipe de développement, et tandis que la question elle-même, soit corrigé dans WEBDAV 7.5, des réglages restaient à faire.


Ils ont également fournis le lien suivant pour plus d’informations :
http://www.iis.net/ConfigReference/system.webServer/webdav/authoring

Le paramètre qui peut influer sur le comportement en question est l’attribut: ‘maxAllowedXmlRequestLength’.

Celui-ci n’est pas configurable depuis l’interface WebDAV dans Microsoft IIS. Cependant, il peut être paramétré avec la commande Appcmd.exe afin définir le PROPFIND à 30 Mo. Voici la commande :

Appcmd.exe set config "Default Web Site" -section:system.webServer/webdav/authoring /
maxAllowedXmlRequestLength:31457280 /commit:apphost

En effet, cette valeur est par défaut de 4 Mo. Celle-ci est documentée dans la base de connaissance Microsoft KB957001. De plus, elle concerne uniquement le fichier de réponse XML et non le taille et le nombre de fichiers…

L’augmentation de ce nombre à 30 Mo améliore sans aucun doute la performance de téléchargement de certains clients.

Malgré cette amélioration, d’autres clients peuvent toujours prendre encore plus de 10 heures pour télécharger leur package.  Dans ce cas, la seule solution de contournement est de faire votre package d’un seul tenant (Un seul fichier MSI) à l’aide d’un outil tiers (WISE, Installschield, etc.).


Sources : Microsoft support Team ConfigMgr


Michel PICOLLET | EXAKIS Paris

Consultant Senior Microsoft [System Center]
mpicollet@event-horizon.emea.microsoftonline.com

Catégories :SCCM Étiquettes : , , , ,
%d blogueurs aiment cette page :