jeudi 20 décembre 2012

[Windows Intune] Usefull links

Intune is a great tool for small companies that can't afford SCCM 2012 or for companies that don't need special features that are only available in SCCM 2012 and that make the choice of the cloud.

Microsoft just released the last version called "Wave D".

In this article, I would like to share with you my list of the most important resources for Windows Intune.

Windows Intune website: : General presentation, video...


Jump Start:

What's New in Windows Intune:
Getting Started Guide:

Microsoft Virtual Academy:

Mobile management with SCCM 2012 SP1 and Intune :
 - Part 1: Configure Windows Intune connector in SCCM 2012 SP1:

Intune for partners:

See you soon !


[Windows 8] Usefull links

You certainly heard of Windows 8.
 Probably that you even installed that OS on a PC to test it.

Surprised by lack of Start Menu ? Did you ever tested that OS on a touch device ?

In this article, I would like to share with you my list of the most important resources for Windows 8.

To start, I recommend you to watch a global presentation of some features in Windows 8 Entreprise :
If you've got time, you can watch the rest of the series (unless perhaps the first episode)/

Plan for and deploy Windows 8:

Windows 8 Library:
What's New:
Deployment with the Windows ADK:

Introducing Windows 8: An Overview for IT Professionals (Final Edition):
Windows 8 and Windows RT Product Guide:
Windows 8 Product Guide for Business:

Download Windows 8 Enterprise Evaluation:
Windows Assessment and Deployment Kit (ADK) for Windows® 8:
Microsoft Deployment Toolkit (MDT) 2012 Update 1:
Microsoft Assessment and Planning Toolkit (MAP):


Windows 8 Deployment:

Technical Training:
Microsoft Virtual Academy:
Partner Readiness Kit:

Windows 8 for partners:
Jump Start: 
Download Campaign (Presentation Deck, Battle card...):

Licensing and Volume Activation

See you soon !

jeudi 13 décembre 2012

[SCCM 2007] [SCCM 2012] Computer Accounts behavior in Collections

Your probably noticed some changes between SCCM 2007 and SCCM 2012 on the computer accounts behaviors in collections mainly during computers re-installation or accounts deletions.

In this article, I'll give you some results from my own experience.

Before starting, I would like to tell you about how SCCM 2007 and SCCM 2012 handle computer accounts in a Collection. You probably know the "GUID" or the "SMS Unique Identifier" called "Configuration Manager Unique Identifier" in SCCM 2012. This ID is used to identify the client, however, for internal management, SCCM uses another field called "Resource ID".

Properties for a SCCM 2007 client

Let's look at the Collection_Rules table, to understand how rules are stored in SCCM. In this case, I created a direct rule :

However "Resource ID" can be changed even if the client GUID is the same.

Computer Refresh
In this scenario, Windows XP, 7 or 8 is working on the client computer and OSD task sequence is launched. Data and configuration are saved during first steps.

With SCCM 2007, Resource ID is the same before and after the task sequence. Computer account remains in the same collections and advertisements are applied again.

With SCCM 2012, Resource ID is regenerated. If you created direct rules, collection attachments are lost !

There is a problem with direct rules in SCCM 2012 without SP :
If you check the collection properties, you can confirm that the computer account is still registered. However, the computer account never appears in the collection.

...look what happens with the other scenarios.

New Installation
In this scenario, the computer boots directly on WinPe (PXE, CD, USB key...).

In SCCM 2007 in native mode and in SCCM 2012, Resource ID is the same before and after the task sequence. Computer account remains in the same collections and advertisements are applied again.

In SCCM 2007 in mixed mode, a new computer account is created with a new Resource ID. The previous computer is marked as obsolete. In the console, depending on you settings, you can merge manually the two accounts to attach the new account to the last account collections.

Account suppressed and recreated (thanks to Heartbeat Discovery) :
In this scenario, you just remove the computer account. The computer account is recreated few time later during heartbeat discovery.

Both in SCCM 2007 and SCCM 2012, the new computer account is recreated with a new Resource ID.

In SCCM 2007, direct rules are removed.
In SCCM 2012 without SP, direct rules are not correctly handled. As for "computer Refresh", you still see your direct rules, but the computer account never appears in the collection.

So What's wrong with direct rules in SCCM 2012 without SP ?
 Let's look at the database again : The Resource ID has been incremented to 16777219...

..., however the direct rules always point to the old Resource ID (16777218).

There is no obsolete account functions... To solve that situation, you need to :
 - Remove your old direct rules
 - Click on Apply. Otherwise, your new direct rule will still point to the previous Resource ID...
 - Recreate your direct rules

We hope that this mistake will be solve in the SP1 :

That's certainly a good reason to test "User Affinity" and to start to deploy applications on users :-)

See you soon !

lundi 3 décembre 2012

[SCCM 2007] Task Sequence fails because boot image is inaccessible on SMSPXEIMAGES$

Take a really common OSD Task sequence (for example the default Deployment task sequence) where you need to restart on WinPE.
You deploy normally boot image on PXE point (shares like \\MyServer\SMSPXEIMAGES$) and everything works fine : You press F12, the computer starts with PXE, loads the boot image...
and you get the following error message !?! :

Obviously, someone will tell me that a SMSPXEIMAGES$ share is not a "real" Distribution Point. It's only made to boot on PXE.
To avoid that problem, people deploy images everywhere : on PXE shares (SMSPXEIMAGES$ share) and "Real" Distribution Points.

Wrong and Really Wrong ! And I'll prove i:

Let's look at the smsts.log file when the client tries to check if all packages used in the Task Sequence are available. We can perfectly note that the client tries to access the boot image on the SMSPXEIMAGES$ share but something seems wrong because it tries to do that several times.

If we check access rights, we can notice that the default access rights set on the SMSPXEIMAGES$ share are too restrictive. Indeed, only the local administrators group and the system account can access it.

In order to solve that problem, I recommend to add at least the read access right to the Network Access Account on the SMSPXEIMAGES$ share.
The default NTFS rights are OK.


For more :
You are probably not totally satisfied of my explanation. Indeed, how a client can start on a boot image and can't access the same image few seconds later ?!

When a client boots with PXE, the boot image is not downloaded from the SMSPXEIMAGES$ share but through the WDS service and the TFTP protocol. WDS service runs with the system account and doesn't have any problem to access the boot images.
On the contrary, latter, when SCCM client tries to access the boot image, it used the SMSPXEIMAGES$ windows share.

Moreover :
In certain circumstances, you can get that error randomly with a Task sequence !
Imagine a task sequence where no step consists on restarting on WinPE excepted for the initial boot with PXE (for example, the defaut "Build and Capture" task sequence).

If several task sequences (with several boot images) are advertised on a client, do you know what boot image will be distributed by PXE ?
The client will load the boot image of the latest task sequence advertised on the computer account !
I let you imagine scenarios where depending on the assignments of the collections and the advertisements, 2 computers can have exactly the same task sequence but start on different boot image.

If the boot image loaded on the client corresponds to the task sequence that you select, the task sequence simply starts.

But what happens if you choose a task sequence that requires another boot image than the one loaded ?
The client downloads the right boot image, configures the hard disk boot parameters to start on that boot image, requests the user to eject the CD and restarts the computer. Task sequence starts as soon as the boot image is loaded on the computer.

If the client can't download the boot image, task sequence fails !
That will happen if the boot image is deployed only on the SMSPXEIMAGES$ shares and if you don't modify right access as recommended.

If you provide the read access right to the network access account on the SMSPXEIMAGES$, everything will work fine.

Tricky to understand ? Let's take an example :
On one hand, an OSD Task sequence called "TS1" that use the boot image "Boot1". That task sequence is advertised (not mandatory) on the collection "Coll1".
On the other hand, another OSD Task sequence called "TS2", that use the boot image "Boot2" and that is advertised (not mandatory) on the collection "Coll 2".

You have 2 computers called CompA and CompB.
You add CompA in Coll1 and Comp B in Coll2. You wait few minutes and you add CompA in Coll2 and Comp B in Coll1.
The task sequences TS1 and TS2 are advertised on both computer. However, with PXE, CompA will boot the "Boot2" image and CompB will boot the "Boot1" image. Ok ? fun :o)

Both computers are started and on the SCCM OSD client wizard, you select the task sequence TS1.
No problem for CompB because "Boot1" is already loaded. Task sequence TS1 starts.
For CompA, client must download "Boot1". However that operation will not be made through PXE service but through the windows shares. If client can't download boot image, task sequence fails.

See you soon !

mercredi 28 novembre 2012

[SCCM 2012] Comment faire apparaitre une nouvelle machine dans une collection de déploiement à la vitesse de l’éclair ?

Vous aurez remarqué que lorsque l'on importe une nouvelle machine dans SCCM 2012, il faut un temps incroyable pour que celle ci apparaisse dans la collection cible.

Avant un prochain article décrivant quelques bizarreries sur les collections dans SCCM 2012, je vous recommande l'excellent article de Michel PICOLLET qui partage ses investigations et nous donne la solution :

Merci Michel :)

@ très bientôt

mercredi 26 septembre 2012

SCCM 2012 dans une architecture multi-forêts

Il est très fréquent dans les grandes entreprises de trouver une architecture Active Directory composée de plusieurs domaines, voire de plusieurs forêts avec ou sans relations d'approbation. Cette segmentation permet de sécuriser et de limiter l'interaction entre les différentes entités et équipements de l'entreprise. Cette organisation amène tout un ensemble de questions lorsqu'il s'agit d'implémenter SCCM afin de gérer les serveurs et/ou les postes répartis sur ces différents domaines et forêts.

Avec SCCM 2007, on avait généralement pour habitude de calquer l'architecture SCCM sur l'architecture Active Directory. On plaçait donc un premier site primaire central dans la forêt de ressources principale, puis des sites enfants dans les sous-domaines et forêts. Au sein d'un même domaine, on pouvait créer plusieurs sites SCCM 2007 afin de maîtriser la bande passante nécessaire aux réplications entre des sites géographiques différents.
Note : Contrairement à une idée répandue, il n'est pas nécessaire d'avoir une architecture en mode natif (authentification des clients via certificat) pour établir des liens entre des sites SCCM 2007 situés dans des forêts différentes même sans aucune relation d'approbation.

Quels sont désormais les grands principes dans SCCM 2012 pour gérer des postes répartis dans des forêts AD différentes ?
  • Créer un site enfant dans une forêt distante. Gros changement par rapport à SCCM 2007 : Cette solution impose d'avoir une relation d'approbation bi-directionnelle entre les 2 forêts. Attention, de nombreux blogs (même officiels) oublient ce pré-requis et construisent des architectures SCCM 2012 comme sous 2007. Le Technet et le support sont pourtant fermes et sans appel : ce prérequis est obligatoire pour permettre aux réplications SQL d'opérer correctement.
  • Installer un site system (un serveur disposant d'un rôle SCCM) dans une forêt distante. En effet, il n'est pas nécessaire que tous les serveurs d'un site SCCM 2012 soient dans le même domaine ni dans la même forêt. Il n'est même pas nécessaire que les différents domaines/forêts aient la moindre relation d'approbation. Lors de l'installation du site system, il est nécessaire de fournir un compte disposant des droits d'administrateur local sur ce serveur. C'est ensuite ce compte qui servira pour communiquer en le Site System et le Site Server (serveur principal d'un site SCCM)
  • Gérer directement les postes depuis des serveurs SCCM situés dans une autre forêt. En effet, rien n'impose encore qu'un poste et le serveur SCCM qui le gère soient dans le même domaine. Rappelons à ce titre, qu'il est même possible de gérer des postes en workgroup. Quelques précautions s'imposent néanmoins pour localiser correctement les serveurs SCCM quand on ne peut pas utiliser Active Directory.

Quelles sont les impactes directes sur l'architecture ?
Nous voyons clairement que SCCM ne peut plus suivre l'architecture Active Directory si les différentes forêts ne sont pas liées entre elles par des relations d'approbation bi-directionnelles !

Retenons 2 principes de bases sous SCCM 2012 :
  • Tous les Site Servers doivent être situés dans la même forêt (ou dans des forêts ayant une relation bi-directionnelle, ce qui est rarement le cas quand on souhaite justement isoler les différents environnements).
  • Par contre, au sein d'un même site primaire, il est possible de créer plusieurs Management Point et Distribution Point que l'on répartira dans les différentes forêts et domaines à couvrir.
Je rappelle qu'il est possible d'avoir jusqu'à 10 Management Point par site primaire. Il est donc possible de couvrir 10 forêts/domaines différents par site primaire. S'il faut en couvrir d'avantage ou si on souhaite mettre plusieurs MP par forêt/domaine, il faut alors multiplier le nombre de sites primaires et avoir recours à un CAS.

Et dans la pratique, çà donne quoi ?
Prenons l'exemple d'une entreprise avec :
 - 2 forêts appelées ROOT (la forêt de ressource) et CORP (la forêt contenant les postes de l'entreprise)
 - 3 emplacements géographiques : Londres, Paris et New-York
Les serveurs de la forêt de ressource ROOT sont principalement localisés à Paris.
Les postes de la forêt CORP sont localisés à Paris, Londres et NY
Nous souhaitons bien évidemment être capable de gérer convenablement la réplication entre les sites géographiques.

Pour commencer, voici, l'architecture à ne surtout pas faire sous SCCM 2012 :

Notons qu'il faut :
 - un site Central + 4 sites primaires (voire 6 si on avait voulu gérer des serveurs dans la forêt Root à Londre et Paris).
 - 5 serveurs SCCM (voire 7)
C'était tentant, mais c'est malheureusement tout à fait impossible. Bref, n'en parlons plus !

Maintenant regardons comment nous pouvons simplement faire une architecture SCCM 2012 en gardant quelques (vieux) réflexes de SCCM 2007 :
 - Toujours, plusieurs sites primaires (3), donc un CAS.
 - Les sites servers sont installés dans chaque pays dans la forêt de ressource (on y ajoute au passage les rôles MP et DP).
 - Dans chaque pays, on installe également un site system dans la forêt CORP avec les rôles MP et DP. Ce sont ces site system qui vont gérer les serveurs dans CORP.

Bilan : Nous avons donc au total 1 CAS, 3 sites primaires pour un total de 7 serveurs.
Pas tellement optimisé mais au moins, çà marche !

Pour aller plus loin... Je vous propose alors cette architecture :

1 seul site Primaire standalone et seulement 4 serveurs !
Nous voyons clairement comment désormais, avec SCCM 2012, il est possible de réduire le nombre de sites, de serveurs et donc le coût global de la solution.

J'entends déjà ceux qui se demandent comment je vais gérer mes réplications entre les 3 sites géographiques. Pour y répondre, je vous propose de me retrouver dans un prochain article où je détaillerai les différentes manières de gérer la bande passante dans SCCM 2012, y compris au sein d'un même site.


jeudi 20 septembre 2012

Patcher les Clusters Windows

Le patching des serveurs Windows est un sujet ultra classique dans les entreprises. Microsoft répond à cette problématique via WSUS et SCCM. D'ailleurs depuis SCCM 2007, ce produit s'appuie sur le moteur de WSUS pour détecter les patchs nécessaires sur les postes, mais utilise ensuite ses propres mécanismes pour la distribution afin d'apporter d'avantage de fonctionnalités telles que les fenêtres de maintenance ou la possibilité d'interdire le redémarrage du serveur.

Le sujet devient autrement plus compliqué dès qu'il faut patcher des clusters...
Pour automatiser le déploiement de patchs sur les clusters, certaines entreprises tâchent de mettre les différents noeuds dans des fenêtres ou des groupes de patching différents. Les noeuds rebootent ainsi à des moments différents.
Ce fonctionnement trouve vite ses limites, quand les ressources n'ont pas basculé correctement ou lorsqu'un noeud n'a pas correctement redémarré.

Et qu'est ce que dit le Support Microsoft ?
Aussi étrange que cela puisse paraître, pour le patching d'un cluster, le support Microsoft n'a guère que la KB174799 : Patching Windows Server Failover Clusters à proposer, c'est à dire, une procédure manuelle. Rien d'automatique !
Dans une réponse récente, le support précise aussi que la fonctionnalité de bascule des ressources cluster est une fonctionnalité de protection qui ne doit pas être mis en oeuvre en fonctionnement nominal. Il est donc hors de question de laisser un serveur redémarrer (donc d'appliquer un patch nécessitant un redémarrage) alors qu'une ressource est en cours d'exécution. Pour Microsoft, il est en effet préférable que la bascule des ressources soit supervisée par un opérateur .

A noter que les cluster Hyper-V échappent à cette règle. En effet, grâce à SCVMM, il est possible de passer un noeud en mode maintenance entraînant le déplacement automatisé et sécurisé de toutes les ressources sur les autres nœuds actifs.

Que peut-on faire à court terme ?
Reste à trouver une solution pour patcher les clusters, certes sans revenir à un processus entièrement manuel, mais surtout sans risquer des casser les ressources hébergées (et en général critiques).
Il est, je pense, évident pour tout le monde que la production est prioritaire, mais qu'il faut tout de même appliquer ces patchs quand cela est possible. A court terme, la meilleure solution trouvée a donc été de préserver l'intégrité d'une ressource en interdisant de patcher le nœud sur lequel elle s'exécute plutôt que de patcher ce nœud au risque de corrompre cette ressource.

La solution retenue a donc été de rester sous WSUS en mettant les nœuds des clusters dans des groupes différents. A la charge pour les opérateurs de déplacer les ressources sur les bons nœuds avant chaque fenêtre de patching. Jusque là, rien de très nouveau même si le dernier point implique un travail manuel important pour les opérateurs.

Pour éviter les oublis et les catastrophes, un script est chargé de vérifier périodiquement sur chaque nœud si une ressource s'exécute et interdit dans ce cas l'installation automatique des patchs.
Les tentatives pour déplacer automatiquement les ressources par script se sont soldées par de gros échecs, principalement en raison de la complexité du processus.

Schématiquement, voila ce que çà donne :

Vous pouvez télécharger le script AutomaticPatchInstallation. Vous trouverez avec ce script la procédure d'installation/désinstallation ainsi que la procédure de patching d'un cluster avec cet outil.

Sympa le Bricolage ! Maintenant que la production est sécurisée, qu'elle solution plus pérenne peut être mise en place ?
Je l'avoue, c'est un peu du bricolage ;o) mais ce bricolage permet d'offrir rapidement une solution pour que les applications critiques conservent leur base SQL en état de marche (pas mal, non ?)

Reste bien évidement encore à trouver une solution nécessitant moins d'intervention manuelle tout en garantissant la sécurité du processus.
Notre cahier des charges est alors le suivant :
 - Un Cluster n'est patché que si tous ses noeuds sont en bonne santé
 - Les ressources doivent être déplacées d'un noeud à un autre automatiquement mais de manière sécurisé
 - L'ensemble du processus doit être supervisé et facilement adaptable aux spécificités des applications.

La Suite System Center 2012 est bien évidemment tout indiquée :
 - SCCM 2012 se charge de patcher les noeuds
 - SCOM 2012 se charge de superviser l'état du cluster et de ses noeuds
 - SC Orchestrator 2012 se charge quant à lui d'orchestrer les opérations

Le processus de déploiement sécurisé des patchs sur les nœuds d'un cluster est alors le suivant :

Le codage de workflow dans SC Orchestrator 2012 peut être plus ou moins long selon le niveau de service attendu mais nous voyons déjà toute l'intérêt de SC Orchestrator 2012 pour effectuer des tâches courantes d'administration.


mardi 18 septembre 2012

Récupérer les bon Logs dans SCCM

Tout Troubleshoot commence par chasser les bons logs. Le terme n'est pas trop fort parce que, soyons honnêtes, SCCM en génère beaucoup qu'il dispose un peu partout, autant sur les serveurs que sur les postes de travail. D'ailleurs Microsoft a jeté l'éponge et ceux qui ont lu la page Technical Reference for Log Files in Configuration Manager ont certainement été surpris en lisant :

Locating Configuration Manager Logs
By default, Configuration Manager log files are stored in a variety of locations that depend on the process that creates the log file, and on the configuration of your site systems. Because the location of the log on a given computer can vary, use search to locate the relevant log files on your Configuration Manager computers to help you troubleshoot a specific scenario.

Il y a donc les consultants qui cherchent désespérément les logs PXE au milieu les autres logs SCCM, les techniciens qui ne remontent pas les bon smsts.log, etc...

Pour vous faciliter la vie (et/ou les aller-retours inutiles), je vous propose plusieurs idées :
  • Pour capturer rapidement et sans faute des logs, j'ai aussi mis au point un script qui peut capturer sur un poste local ou distant (pour peu que votre compte puisse y accéder par les partages administratifs) tout un ensemble de logs. Bien entendu, ce script peut aisément être adapté à n'importe quel produit (ou même copier autre chose que des logs), mais j'ai déjà défini les principaux logs pour les serveurs et les clients SCCM.
Vous pouvez télécharger LogHunter.vbs.

En ligne de commande, la syntaxe est toute bête :
cscript.exe logHunter.vbs [IP / Nom Distant]

Si aucun argument n'est fourni, le script cherche les fichiers sur le poste local.

Si vous fournissez un nom de poste distant par argument, le script transforme tout seul le chemin local en un chemin UNC (donc C:\logs est transformé en \\OrdiDistant\C$\Logs)

Les répertoires à récupérer sont stockés dans un répertoire généré au même emplacement que le script (donc nickel avec une clé USB par exemple pour troubleshooter un déploiement qui se passe mal). Le nom du répertoire est de la forme YYYYMMDD.HHMM-NomOrdinateur

La personnalisation les répertoires à récupérer se fait tout simplement en éditant les premières lignes du script : Il s'agit d'un tableau, où chaque élément est de la forme
"Répertoire local à récupérer | Nom du répertoire de copie".

Ainsi, si je lance le script sur l'ordinateur TOTO avec comme instruction "C:\logs|Logs_sur_C", j'aurai à coté de mon script le répertoire 20120918.214-TOTO avec à l'intérieur le répertoire "Logs_sur_C" qui contient une copie des fichiers contenu dans C:\logs
Je vous laisse étudier les autres exemple fournis avec le script.

Un script à garder pas trop loin et à mettre entre toutes les mains si vous souhaitez qu'on vous rapporte des logs exploitables :o)

N'hésitez pas à me faire des retours

Bon Troubleshoot

dimanche 16 septembre 2012

Sélection de Stencils Visio

"Un schéma vaut mieux qu'un long discours". Cette expression attribuée à Napoléon est toujours d'actualité surtout avec des produits aussi complexes que ceux de la suite System Center.

Je vous propose une petite sélection de Stencils Visio plus ou moins récents, mais toujours très utiles.
Vous pouvez les téléchargez ici.
J'en profite pour saluer au passage toutes les personnes à qui nous devons ces Stencil.

Pour commencer les ITPro_PosterStencils et les ITStencils pour faire des Schémas comme sur le Technet (la clâsse !! ) :

 Les objets pour SCCM 2007 et SCCM 2012 (v0.9, un grand merci à Jean Sébastien Duchêne) :

SCOM 2007 :

Tout un ensemble d'objets autour de la Virtualisation et de HyperV : Virtualization 2008 et Virtualization_Modern :

et pour finir, quelques Stencils VMWare :

A vous de Jouer !!

jeudi 6 septembre 2012

CAS ou Pas CAS... avec le SP1

Débat débuté dès la sortie des premières versions de SCCM 2012 et qui continue à faire parler de lui dans les entreprises : "Faut-il installer un CAS ou pas ?"

Pour bien commencer, rappelons ce qu'est un CAS :
Par rapport à SCCM 2007, l'organisation des Sites SCCM 2012 s'est vue fortement réduite : il n'est plus possible de mettre un site primaire enfant sous un autre site primaire parent. Un site primaire peut seulement héberger des sites secondaires (250 max par site primaire). En contrepartie, il est possible de mettre jusqu'à 10 Management Point par site primaire et de gérer jusqu'à 100.000 clients (25.000 client max par MP).

Dans certains cas, on peut faire le choix d'implémenter un site central appelé CAS (Central Administrative Site) permettant d'administrer plusieurs sites primaires. Ce site n'a pas vocation à gérer de clients mais seulement à :
  • Gérer la réplication entre les sites primaires
  • Donner une vision globale de l'infrastructure (reporting...)
  • Centraliser l'administration des différents sites primaires
Note : On parle de hiérarchie quand une infrastructure SCCM contient un CAS avec un ou plusieurs sites primaires. Une infrastructure constituée d’un site primaire "standalone" (sans CAS) et de sites secondaires n’est pas considérée comme une hiérarchie puisque les sites secondaires ne sont pas acteurs dans l’administration de la solution.

Quand doit-on mettre un CAS ?
Je vous renvoie à l'excellent article de Brian Mason listant les raisons pour lesquelles il faut installer ou éviter d'installer un CAS :

Retenons les grands principes :
  • Si vous avez plus de 100.000 clients à gérer
  • Si votre infrastructure SCCM contient plusieurs sites primaires (voir le chapitre dédié à ce sujet)
  • Si vous souhaitez simplifier certains aspects de vos restaurations (je parle de recovery, pas de manger pour pas cher, hin ;)). En effet, votre paramétrage étant répliqué entre le CAS et ses sites primaires, lors de la restauration d'un site il est possible de récupérer certaines données depuis le reste de l'infrastructure. Cependant, cela ne dispense absolument pas de faire des backup, mais disons que votre infrastructure sera plus rapidement opérationnelle avec notamment un inventaire à jour.
  • Parce que cette fonctionnalité requière une machine super puissante (
  • Parce que cette machine supplémentaire requière nécessairement des licences, des coût de runtime...
  • Parce que ce serveur supplémentaire, entraînant des réplications SQL et complexifiant votre infrastructure, demande un effort supplémentaire de gestion et apporte son lot de causes de pannes supplémentaires.
Grosso modo, on peut estimer que dans 95% de cas, il n'est pas utile d'installer de CAS.

Quand doit-on avoir plusieurs sites primaires ?
Avoir plusieurs sites primaires implique forcément avoir un CAS. Reste à savoir si le contexte nécessite d'avoir plusieurs sites primaires comme dans SCCM 2007, au risque (encore une fois) de complexifier l'infrastructure.

En effet, SCCM 2012 a fortement diminué les raisons pour lesquelles il faut installer plusieurs primaires : il est notamment possible d'avoir plusieurs politiques clients au sein d'un même site, d'avoir des connexion HTTP et HTTPS (mode mixte et natif sous SCCM 2007) et la délégation a été très nettement améliorée.
Sous SCCM 2007, il était aussi souvent nécessaire de créer plusieurs sites pour gérer des forêts sans relations d'approbations. Au contraire sous SCCM 2012, les relations inter-sites nécessitent des relations inter-forêts bi-directionnelles (réplication SQL oblige). Les relations inter-forêt non-bidirectionnelles ne peuvent être gérées qu'au sein d'un site. (Nous étudierons cette question épineuse dans un prochain message).

On peut vous imposer politiquement ou pour des raisons de sécurité... d'avoir plusieurs sites primaires mais avec ce CAS, vous aurez de toute façon une vision centrale, des réplications et la possibilité de lancer des opérations sur tous vos sites primaires.

Bref, vous l'avez compris, si vous avez moins de 100.000 clients, il est peu probable que vous ayez besoin d'avoir plusieurs sites primaires.

Sur le technet, Microsoft présente un scénario avec 2 sites primaires (et encore, on n'exclue pas d'utiliser un site secondaire et une délégation correctement appliquée) : 2 sites géographiques gérés par 2 équipes techniques différentes selon des règles de gestions différentes. On pourrait envisager d'avoir 2 sites primaires standalone mais ils veulent avoir une vision de l'ensemble ce qui implique l'installation du CAS.
Si le scénario est intéressant, le cas risque d'être assez rare dans la vie réelle :o)

Pourquoi un tel débat ?
Jusqu'à présent ce choix était crucial puisque contrairement à SCCM 2007 qui permettait d'attacher/détacher n'importe quand un site primaire à une hiérarchie, sous SCCM 2012, un site primaire doit être rattaché dès son installation à son CAS ; sinon, il restera à jamais un site Standalone.
Le problème se pose donc par exemple quand aux potentiels projets de fusion/acquisition d'une entreprise : Certains administrateurs souhaitent installer un CAS dans le cas où l'entreprise voudrait rattacher une entité indépendante à son infrastructure SCCM 2012. Notons pourtant qu'il ne sera pas possible de rattacher à postériori une site primaire à un CAS. A partir de là, le débat fait rage quand à la vraisemblance de tels scénarios et au travail qu'il faudra de toute façon fournir.

Prochainement, cette limitation ne sera plus un argument puisque parmi les améliorations annoncées dans SCCM 2012 SP1, on trouve la possibilité "d'étendre" un site primaire standalone en installant un CAS qui lui est alors rattaché. Le Technet indique déjà la marche à suivre :

A noter qu'il sera seulement possible d'étendre un primaire standalone. Il ne sera donc toujours pas possible de rattacher à postériori un site primaire standalone à une hiérarchie existante. Par contre, le SP1 encore nous permettra de réaliser des migrations d'un environnement SCCM 2012 SP1 vers un autre environnement SCCM 2012 SP1. Typiquement, il sera donc possible de fusionner ou d'exporter des infrastructures SCCM 2012 SP1. On pourra aussi utiliser cette fonctionnalité pour faire communiquer des environnements de test, pré-production et production. Promis, on en reparle...

Pour info, voici la liste complète des améliorations prévues dans le SP1 :


Ajout du 14 sept 2012 : Je vous disais qu'un CAS pouvant simplifier les opérations de restauration... mais elle peut aussi les compliquer grandement.
Simplifier : parce que si un primaire ou un CAS tombe, l'autre site peut retransmettre des informations à l'autre site après la restauration. Pratique donc surtout si les sauvegardes sont espacées.
Compliquer grandement : Lors de la restauration d'un CAS, celui-ci passe en mode maintenance tant que TOUS les sites primaires ne sont disponibles. De son coté, lors de la restauration d'un site primaire, il fait indiquer le nom du serveur CAS et que celui-ci soit fonctionnel. Dans le cas (extrême mais possible) où il faudrait restaurer un CAS + un site primaire, la réinstallation de chaque site nécessitant que l'autre site soit opérationnel, l'affaire tourne à la réinstallation intégrale de l'infra :-(

lundi 3 septembre 2012

Technet in the Pocket

Le Technet, c'est bien ! C'est même notre Bible à tous (n'est ce pas, hin !?!). Par contre, l'affaire se corse en l'absence d'une connexion Internet ou pour faire des recherches...
C'est sans doute parce que vous ignorez qu'il est possible d'exporter des groupes entiers d'articles.

Dans cet article, je vais vous montrer comment en quelques clics, il est possible d'exporter jusqu'à une centaine d'articles dans un PDF.

Tout se joue depuis l'icone d'impression en haut à droite du Technet.
 - Cliquez dessus et sélectionnez Print Multiple Topics

Une fenêtre d'aide apparaît.
 - Cliquez simplement sur Start


Vous revenez à votre documentation Technet. A cela près qu'une barre vous permet de gérer votre sélection d'articles.
 - Cliquez avec le bouton droit sur un article ou une rubrique.
Un menu vous propose d'ajouter cet article ou tous les articles de la rubrique (et vous indique le nombre).

Créez votre compilation selon vos besoins.
Actuellement, une compilation est limitée à 100 articles maximum. Si en sélectionnant une rubrique, vous voyez (100+), c'est qu'il y a trop d'articles à ajouter dans votre compilation.

 - Une fois terminé, cliquez sur Collection (XX Topics)

Vous retrouvez toutes les rubriques et articles que vous avez sélectionné.
 - Vous pouvez modifier l'ordre des éléments, créer des chapitres et même personnaliser le nom de votre "livre"
 - Dans la partie Avancée, sélectionnez votre format de sortie : HTTP / PDF
 - Cliquez sur Generate

La génération peut prendre plusieurs minutes selon la quantité d'articles sélectionnés.
 - A la fin, cliquez sur Download Your Document

Dernièrement, j'ai pu exporter l'intégralité de la documentation Technet SCCM 2012 dans 5 PDF. Vous les trouverez sur mon espace SkyDrive publique :
Je tâcherai de les mettre à jour régulièrement.

Bonne lecture

jeudi 30 août 2012

SCCM 2012 : Où trouver l'information ?

Comme je l'annonçais précédemment voici un post dédié uniquement à l'information autour de SCCM 2012.

S'il ne faut retenir que 2 liens, il s'agit bien entendu de :
Au milieu de tous ces liens, je vous propose de découvrir ceux que j'affectionne particulièrement :
  • Configuration Manager Guides : L'auteur de ces guides a fait un travail formidable depuis les toutes premières version de SCCM 2012 (et de SCCM 2007). Il décrit pas à pas l'installation des principales fonctionnalités de SCCM.
    Cela commence par l'installation d'un primaire tout simple. On ajoute la gestion des updates, pour ensuite déployer un appli. On aborde aussi le déploiement de Windows 7 et la gestion offline des images pour ensuite faire un petit détour par MDT et Windows 8. Comme c'était un peu trop simple, il nous présente aussi l'installation d'une architecture avec un CAS. Bref, trouvez une machine, votre moniteur d'auto-école n'attend que vous !!
  • Troubleshooting and Gotchas : Ce wiki, avec encore peu de liens (preuve que le produit fonctionne à merveille, hin !!), regroupe des articles vers les principales KB, tips et liens nécessaires pour la résolution d'incidents.
  • Self-Study Guide : Dans la 3ème partie, Microsoft met à disposition tout un ensemble de Labs (Virtual Labs), de Vidéos (Microsoft Virtual Academy) et de liens pour découvrir et se perfectionner sur SCCM 2012.
  • Microsoft Private Cloud Guided Labs : Ces Labs abordent différents scénarios autour du Cloud dont certains faisant appel à SCCM.

Avant de clore cet article, je ne peux que vous conseiller de suivre attentivement les blogs de l'équipe produit SCCM et de l'équipe support.

Enjoy :o) !!

mardi 28 août 2012

Suivre l'actualité des produits Microsoft

Le moindre que l'on puisse dire, c'est que la communication autour des produits Microsoft est extrêmement importante, d'autant que la moindre annonce officielle ou officieuse est très vite reprise, transmise et commentée par la communauté. Cette quantité d'information peut très vite effrayer et/ou décourager le plus motivé des consultants.

Plutôt que de transmettre à mon tour ces informations, je vous propose de faire un tour des principales sources d'information que Microsoft met à notre disposition. Cette liste n'est évidemment pas exhaustive mais elle devrait vous permettre d'accéder directement aux principaux canaux d'information.

Tout d'abord les newsletters :
Cette page regroupe l'ensemble des newsletters de Microsoft France. Que vous soyez développeur, infra, mobilité, sécurité... il y en a forcément une qui vous convient.
La newsletter IT Pro Technet (inscription depuis cette page) est à mon sens tout à fait indispensable.

Le Profile Center permet également de s'inscrire à des newsletter (notamment en US) et de gérer ses abonnements. N'ayez pas peur de vous inscrire aux newsletters MSDN, technetFlash, Solution Accelerator... vous pourrez toujours à l'usage vous désinscrire.

A noter que le site réservé aux partenaires ( contient quelques newsletters, dont la newletter générale partenaire ( En cherchant un peu (beaucoup même), on trouve aussi une newsletter d'assez bonne qualité sur les Serveurs et le Cloud. Son lien d'inscription est ici :

C'est bon ? Les mailbox sont pleines ?

Alors parlons Blogs : Voici la liste des blogs officiels System Center :
J'y rajoute le blog officiel du groupe produit SCCM

Avant de clore, voici encore 2 blogs que j'affectionne particulièrement :

Server & Cloud Blog :
Plusiers initiatives ont été rassemblées récemment dans ce Blog. On y parle beaucoup moins de technique que dans les précédents blogs mais surtout de scénarios d'usages autour du Cloud. Bref, un blog important mettant en perspective nos différentes technologies.

The Deployment Guy :
Une sorte de blog collaboratif qui fonctionne très bien depuis plusieurs années autour des problématiques de déploiement. On y trouve des retours d'expérience sur MDT, des idées, des outils complémentaires développés par la communauté...

Bien évidemment, chacun de ces sites permet de s'inscrire à un flux RSS. Donc plutôt que de guetter l'information, autant laisser votre client RSS préféré (Outlook le fait très bien) vous avertir dès qu'une information est sortie.

Dans mon prochain post, je vous parlerai plus en détail des liens (hyper) utiles pour SCCM 2012.


lundi 20 août 2012

retour d'expérience sur Windows Intune

En guise de premier post technique, je vous propose de ne parler ni de SCCM 2007 ni de SCCM 2012 mais de la version Cloud du produit proposé par Microsoft, c'est à dire Intune. Tout d'abord, ne confondons pas avec iTunes, logiciel de chez Apple qui n'a franchement rien à voir (On se demandera au passage pourquoi Microsoft a proposé de donner un nom aussi proche - même l'auto-completion de Google vous propose de corriger par iTunes).
Solution Cloud, çà veut donc dire que vous n'avez désormais besoin d'aucune infrastructure. Vous payez et vous utilisez. Actuellement, le prix public de cette offre est de l'ordre de 10$/mois/poste.

Est ce cher ?
Jusqu'à présent, SCCM n'était destiné qu'à des grands comptes voire des PME importantes. En effet, la licence du produit est plutôt élevée (ce qui ne va aller qu'en s'accentuant maintenant que Microsoft vend sa suite SC en entier et non produit par produit) et il faut y ajouter les coûts de l'infra serveur ainsi que les coûts du projet d'intégration, la maintenance et les updates de temps en temps...
Une PME n'avait donc jusqu'à présent guère que l'alternative de faire des inventaires avec quelques scripts et un grand fichier Excel rapidement obsolète et inutilisable...
Ce produit, tout en n'étant pas gratuit, propose donc une solution intermédiaire entre une infra SCCM et être totalement aveugle.

Qu'est ce que propose de faire intune ?
- Déploiement de logiciels
- Déploiement de mises à jour
- inventaire
- reporting
- Antivirus / Antimalware (endpoint protection : une version adaptée pour intune de Forefront Endpoint Protection)
- Stratégie (on ne parle pas de GPO, mais de pouvoir gérer le firewall, l'antivirus et quelques paramètres comme Bits)
- donne un accès à MDOP (Med-V, Add-V...)

Que faut-il pour faire fonctionner intune ?
Aujourd'hui les OS supportés sont :
 - Windows XP Professionnel, SP2 2 ou SP 3
 - Windows Vista Versions Entreprise, Intégrale ou Professionnel
 - Windows 7 Éditions Entreprise, Intégrale ou Professionnelle
Il faut également un accès à Internet (HTTP/HTTPS) puisque tout se fait par là. Les proxy sont supportés mais si le proxy est authentifiant, il faut que le poste puisse s'authentifier avec son compte machine (ce point est important et souvent gênant dans les entreprises avec un contrôle strict des accès à Internet).

On pourrait parler longuement de inTune, mais le plus intéressant me semble de comparer SCCM 2012 avec inTune.
Retenons un principe général du produit : la solution inTune est faite pour être directement utilisable sans fioriture et avec un minimum d'impact pour l'utilisateur (il ne s'en rendra à peine compte ce qui peut dans certains cas devenir problématique, on y reviendra). Le produit propose assez peu de personnalisation, donc soit le produit est suffisant en l'état, soit il est nécessaire de passer sous SCCM. Certaines entreprises préfèreront un produit efficace et rapide plutôt que de devoir faire le choix entre rien et lancer un projet long et couteux sous SCCM. Bien évidement, de la même façon qu'on est toujours mieux riche et en bonne santé que pauvre et malade, s'il est possible d'implémenter SCCM, pourquoi s'en priver ? :o)

SCCM 2012 vs Intune
SCCM 2012 intune
Gestion des postes sur Internet Nécessite l'implémentation une PKI pour commiquer en HTTPS (notons que c'est beaucoup plus facile que sous SCCM 2007) Natif
Regroupement Possibilité d'attribuer un poste automatiquement (collection dynamique) Attribution manuelle seulement
Déploiement de mises à jour Possibilité d'automatiser la validation et le déploiement de certains patchs
Possibilité d'empêcher les reboots (très utile pour les serveurs notamment)
Possibilité d'interagir avec l'utilisateur
Interface très (trop ?) silencieuse.
Alerte hors périmètre SCCM (cf SCOM) Alerte sur l'état du poste
Prise de main distance Prise de main possible uniquement si le poste est dans l'intranet Prise de main seulement sur demande de l'utilisateur
Déploiement logiciel Nombreux scénarios possibles : date de démarrage, date limite, publication, attribution,  interaction avec l'utilisateur...
Utilisation de Task Séquences (2012 pour Internet) pour des scénario avancés (upgrades, rollback…)
Nombreux formats de fichiers exécutables. Nombreux programmes (install, désinstall, réparation…), Définition de prérequis...
Scénarios limités : uniquement attribution avec spécification d'une date limite
Pas de publication, pas de Task Séquence
Seuls les EXE et les MSI sont pris en charge
Uniquement installation et désinstallation. Pas de notion de prérequis...
Stratégie Power Mangement, patching, reboot, personnalisation des messages affichés
Stratégie des agents définissable au niveau des collections (au niveau des sites pour 2007)
Utilisation des GPO (via Active Directory) ou de scripts pour définir des paramètres sur le poste
Stratégie limitées par tournées Utilisateur final : Firewall, information de l'agent, paramétrage des patchs et BITS.
Messages affichés non personnalisables
Stratégie d'agent définissable au niveau des groupes
Fenêtre de maintenance Disponible non disponible
Rapports / inventaire Rapport nombreux et modifiables
inventaire extensible si nécessaire
5 rapports : mises à jour, logiciels, inventaires, licences (x2)
Inventaire non extensible
Asset Management Consolidation avancée à l'aide de services fournis fournis par Microsoft Limité à du reporting
Administration Délégation possible basée sur des rôles ("role based management") Pas de délégation. Nécessité de plusieurs environnements distincts pour limiter des accès.
Sécurisation de l'environnement Approbation des agents entrants Aucune approbation. Il suffit d'installer le client distribué depuis la console d'administration.
Limité par le stockage de l'entreprise
Réplication des sources dans la hiérarchie
Dans l'intranet, un poste peut diffuser ses sources aux postes connexes (fonction Branch Cache)
Limité au stockage acheté dans le Cloud
Chaque poste télécharge ses sources

Quelques liens utiles :
aide :
déploiement : /windowsintune/ff399003.aspx
parefeu et proxy : /windowsintune/ff628135.aspx
Troubleshooting :
Bandwith :
Aperçu technique : je vous renvoie à l'article mon ancien collègue Michel Picollet :

Pour conclure :  intune est un produit encore tout neuf basé davantage sur WSUS que sur un véritable client ce qui le limite dans ses fonctionnalités. SCCM va bien au delà certes ; reste à savoir si le client sera prêt à faire l'investissement. Rien n'empêche d'ailleurs de commencer avec intune le temps que projet SCCM se mette en place. J'ai également vu des clients mettre en place cet outil afin d'avoir une cartographie à jour de leur parc avant, pendant et après leur migration. Notons que Microsoft a prévu l'investir énormément sur le Cloud. Il ne fait aucun doute que intune va évoluer. On parle même de pouvoir interfacer intune avec SCCM.
Personnellement, je pense que dans un contexte sans solution de gestion de parc, tout projet poste de travail devrait proposer l'implémentation de intune. Notons d'ailleurs qu'il est possible d'essayer gratuitement la solution pendant 30 jours, le temps au client de mesurer les bénéfices de cette solution voire d'identifier l'ampleur du "laisser aller" sur son parc.


dimanche 5 août 2012

Welcome on Board

31 ans, bientôt 10 ans d'expérience à Paris et Lyon en tant qu'ingénieur en informatiques et consultant en SSII dont 7 années entièrement consacrée au Design et aux Déploiements des Postes de Travail... et je crée enfin mon blog.

Pourquoi aujourd'hui et pourquoi seulement maintenant ? (et pourquoi raconter ma vie ?)
Comme pour beaucoup, Internet est un outil indispensable dans ma vie de tous les jours. Tout d'abord pour accéder à la documentation officielle et ensuite pour retrouver des retours d'expériences.
Ma première question était donc "faire un blog OUI, mais pour dire quoi ?".
Vous déplorez sans doute comme moi tous ces blogs qui consistent seulement à répéter ce que l'éditeur dit déjà très bien. Les auteurs de ces blogs oublient-ils que nous connaissons comme eux les flux RSS ? bref inutile de polémiquer ou de mes créer des ennemis alors que je commence tout juste ;o)

Au travers de ce blog, je souhaite partager mon expérience, mes interrogations et mes réussites sur tout ce qui touche au Poste de Travail avec Windows XP (et oui...), Windows Seven et maintenant Windows 8 ainsi que les outils de gestion qui l'entourent tel que SCCM, MDT et même SC Orchestrator.