Ayant pris l’habitude d’utiliser ce canal pour vous informer, mais aussi pour partager quelques pensées et prendre note de quelques informations que je jugeais utiles, je continuerai, sans doute, à sévir quelque part sur Internet comme sur https://blog.papp.fr/. Ceux qui me suivent savent déjà qu’il m’arrive de relayer quelques informations via Twitter ou via LinkedIn. La forme du blog est-elle la meilleure ? En tout cas, le message de 120 caractères n’est pas suffisant pour certaines informations.

Mon premier billet date du 1er janvier 2005. C’est en quelque sorte le témoignage d’une bonne résolution de début d’année qui a tenu pendant plus de 10 ans avec, certes, des hauts et des bas.

Je remercie ceux qui ont pris le temps de me lire, de m’inspirer, de m’avoir apporté des précisions (et signalé des fautes d’orthographe ou de grammaire), mais je remercie encore davantage ceux qui m’ont autorisé à publier des informations sur des sujets que nous avions vus lors de mes interventions.

Je remercie mes collègues : ceux qui m’ont alimenté en articles avant de prendre leur envol et de publier sur leur propre blog, mais aussi ceux qui m’ont permis de réfléchir à certains sujets.

Ayant travaillé depuis très longtemps autour des produits Microsoft, il est peu probable que nous ne nous rencontrions pas, à nouveau, dans mes futures fonctions.

N’hésitez pas à faire part de vos commentaires à travers les recommandations sur LinkedIn, car je doute de pouvoir continuer à approuver les commentaires sur ce site !

L’article de David Allen propose de mettre en œuvre via OpsMgr une surveillance du réglage du plan d’économie d’énergie via un script déclenché par un moniteur.

Le script recherche les différents plans d’économie d’énergie définis localement dans root\cimv2\power via une requête :
SELECT * FROM Win32_PowerPlan

En parcourant la liste des plans à la recherche du plan actif, le script compare la valeur trouvée avec celui passé en paramètre.

Le fait de passer par OpsMgr pour ce type de vérification n’est pas, en soi, une erreur. Cependant, je considère qu’il serait plus logique de faire ce type de vérification à travers la gestion de la conformité de ConfigMgr.

La vérification est effectuée toutes les 24 heures via OpsMgr. Je ne suis pas sûr qu’il soit pertinent de vérifier à cette fréquence ; les erreurs de réglage se font généralement à l’installation des serveurs, mais plus rarement une fois les serveurs installés. Le moniteur est conçu de manière suffisamment intelligente pour prévoir une autre fréquence, ainsi que de nombreux autres paramètres.

Le pack est conçu pour un environnement en anglais dans lequel le nom “High performance” est utilisé. Pour des serveurs en français, il faudrait utiliser l’expression “Performances élevées” ; ce qui peut poser quelques problèmes avec les caractères accentuées.

Il existe, sur Internet, des pack de configuration pour surveiller les réglages utilisés en matière de gestion de l’énergie. Ces packs peuvent être utiles dans le cadre d’une démarche d’économie d’énergie sur les postes de travail et de manière complémentaire aux propositions natives de ConfigMgr. Pour les besoins de serveurs, un pack plus simple est largement suffisant qui vérifie le plan choisi et qui remonte une non-conformité si le serveur n’est pas réglé sur les performances maximales ; voire, qui effectue le réglage vers le mode le plus consommateur, certes, mais qui procure les meilleures performances.

Exemple de script de vérification du modèle d’alimentation :

Option Explicit
'=============================================================================
' Microsoft provides script, macro, and other code examples for illustration only,
' without warranty either expressed or implied, including but not
' limited to the implied warranties of merchantability and/or fitness for a particular purpose.
' This script is provided 'as is' and Microsoft does not
' guarantee that the following script, macro, or code can be used in all situations.
'=============================================================================

' Set DCM = False in the script when testing in a command prompt
' Set DCM = True when script used in a DCM configuration item
Const bDCM = False
'Const bDCM = True

On Error Resume next

Dim strResult

Dim strPlan
strPlan = "high performance"

If not bDCM then wscript.echo "Script Started"

Err.Clear

Dim objWMI, colPlans
Set objWMI = GetObject("winmgmts:\\.\root\cimv2\power")

If Err.Number = 0 then
    err.clear
    Set colPlans = objWMI.ExecQuery("SELECT * FROM Win32_PowerPlan")

    If Err.Number = 0 then
        Dim strPlanName, strPlanStatus, objPlan, strState

        For Each objPlan in colPlans
            strPlanName = LCase(objPlan.ElementName)
            if not bDCM then wscript.echo "Nom du plan : " & strPlanName
            strPlanStatus = objPlan.IsActive
            if not bDCM then wscript.echo strPlanStatus
           
            If strPlanStatus = True    Then
                If ucase(strPlanName) <> ucase(strPlan) Then
                    strResult = "Active PowerPlan is Incorrect"
                Else
                    strResult = "OK"
                End If
            End If
         Next
       
        if not bDCM then wscript.echo "Script Complete"
        wscript.echo strResult
    End if
End If

Je qualifie ce correctif de surprenant car il faut retenir que ConfigMgr 2007 est en phase de support étendu ; phase pendant laquelle Microsoft n’est pas censé développer de correctifs en dehors des correctifs de sécurité.

Ce correctif est disponible après inscription selon les procédure décrites sur un précédent billet pour les différentes langues de ConfigMgr 2007 ainsi que les packs internationaux (ICP1 et ICP2 pour International Client Pack).

La première différence réside dans cette dernière expression : si tous les clients de Microsoft peuvent acquérir OpsMgr ou OMS, il faut être client du support Microsoft à travers un contrat Premier pour avoir accès aux RAP as a Service.

Les aspects liés à la technologie sont surveillés par l’ensemble de ces 3 solutions. À des niveaux variables, l’ensemble de ces 3 solutions proposent des conseils face à de mauvais réglages qui ne respectent les bonnes pratiques. Le niveau de ces conseils provient des groupes produits pour OpsMgr et OMS, tandis que le RAP as a Service est alimenté par les retours du support Microsoft et l’expertise des PFE. OpsMgr collecte des informations, non seulement pour détecter des dysfonctionnements, mais également des données permettant d’anticiper des problèmes soit par le fait de mauvais réglages, soit par l’augmentation de la charge. Il collecte également pas mal de données pour aider le diagnostic.

Seul le RAP as a Service s’intéresse aux process mis en œuvre autour des solutions utilisées et à l’organisation des équipes qui les gèrent. Par exemple, si vous n’avez pas de plate-forme pour tester régulièrement votre plan de reprise d’activité, ni OMS, ni OpsMgr ne le saura et ne vous indiquera que ce n’est pas une bonne pratique.

Dans la plupart des cas, il est rare que vous nous demandiez de dérouler un RAP as a Service sur des environnements de développement ou de test, tandis qu’OMS ou OpsMgr peuvent l’être sans problème.

Sans parler de véritable temps réel, OpsMgr réagit très rapidement à des changements d’états de composants surveillés. OMS réalise des points de contrôle à un intervalle régulier, tandis que la collecte d’information du RAP as a Service est réalisée sur demande, à très basse fréquence.

OMS est une solution cloud qui nécessite une connexion à Internet tandis que le RAP as a Service existe en offre pour des environnements déconnectés. OpsMgr peut être installé sur Microsoft Azure pour surveiller des environnements internes, mais c’est une nouvelle tendance car la quasi-totalité d’entre vous utilisent encore des serveurs internes pour héberger votre solution de supervision.

Sans personnalisation, OpsMgr ne délivre pas d’informations très synthétiques qui permettent à un responsable de savoir où il en est. En revanche les affichages d’OMS ou des RAP as a Service sont destinés à être visualisées rapidement.

Pour conclure, outre les aspects complémentaires de chacune de ces solutions, il faut surtout retenir que les PFE peuvent intervenir pour vous aider à mettre en œuvre l’ensemble de ces solutions et à les maintenir.

Pour mémoire, EMS contient, à ce jour, les composants suivants :

• Azure Active Directory Premium (AAD Premium),
• Microsoft Intune,
• Azure Right Management (Azure RM),
• Azure RemoteApp,
• Microsoft Identity Manager 
• le dernier composant, arrivé récemment, Microsoft Advanced Threat Analytics (ATA) issu du rachat d’Aorato.

OMS, pour sa part, étant le dernier arrivé, ne correspond pas vraiment à un ensemble de composants disponibles séparément, mais propose de couvrir les scénarios suivants :

• Log Analytics délivrées par Operational Insights (précedemment, System Center Advisor),
• Automatisation que l’on pourrait considérer comme la nouvelle génération de PowerShell et System Center Orchestrator,
• Disponibilité que l’on pourrait considérer comme l’évolution de System Center Data Protection Manager,
• Sécurité délivré par Operational Insights, également.

Si je m’intéresse à ces deux suites, c’est qu’EMS s’intègre parfaitement avec System Center Configuration Manager (ConfigMgr) et qu’OMS est le complément naturel à System Center Operations Manager (OpsMgr).

Il est extrêmement intéressant de noter que ces offres évoluent à un rythme très rapide (mensuellement) et qu’ils s’enrichissent de nouvelles fonctions régulièrement.

Enfin, l’époque où Microsoft était concentré sur lui-même est complètement révolue : outre des systèmes sous Windows, EMS gère également des systèmes sous Apple iOS ou Google Android, tandis que OMS gère des systèmes sous Microsoft Azure mais aussi Amazon Web Service (AWS), Windows Server mais aussi Linux, Hyper-V, mais aussi VMware ou OpenStack.

Une des nouveautés du SP1 de System Center 2012 R2 Configuration Manager (ConfigMgr 2012 R2) est la mise à jour automatique des correctifs cumulatifs (Cumulative Update ou CU).

Avant le SP1, cette option de mise à jour des clients ne prenait pas en charge les CU mais uniquement la version majeure du client.

Exemple:

• Automatic Client Upgrade activé.
• Site en ConfigMgr 2012 R2 CU3
• Installation du CU4 de System Center 2012 R2 Configuration Manager
• Un poste client en CU3 de System Center 2012 R2 Configuration Manager
• Le poste reste en CU3, il faut déployer la mise à jour du CU4 par package/Software update/SCUP https://technet.microsoft.com/en-us/library/jj553405.aspx#BKMK_DeployUpdates

Autre exemple:

• Automatic Client Upgrade activé.
• Site en ConfigMgr 2012 CU3
• Installation du  de System Center 2012 R2 Configuration Manager , puis du CU1
• Un poste client en CU3 de System Center 2012 Configuration Manager
• Le poste migre automatiquement en System Center 2012 R2 Configuration Manager, mais sans le CU3. Il faut, donc, installer le CU3 après avoir migré le client en ConfigMgr 2012 R2. Il y a, donc, deux mises à jours consécutives.

Depuis le SP2, la fonction Automatic Client Upgrade prend en charge la migration du client vers la nouvelle version majeure, mais aussi vers le nouveau CU.

Exemple:

• Automatic Client Upgrade activé.
• Site en ConfigMgr 2012 R2 CU5
• Installation du SP1 de System Center 2012 R2 Configuration Manager
• Installation du CU1 de System Center 2012 R2 Configuration Manager SP1
• Un poste en CU3 de System Center 2012 R2 Configuration Manager. Le poste est migré automatiquement en CU1 de ConfigMgr 2012 R2 SP1. Il n’y a, donc, qu'une seule mise à jour sur le client.

Autre Exemple :

• Automatic Client Upgrade activé.
• Site en ConfigMgr 2012 R2 SP1
• Installation du CU1 de System Center 2012 R2 Configuration Manager SP1
• Un poste en System Center 2012 R2 Configuration Manager SP1 (sans correctif cumulatif). Le poste est migré automatiquement en CU1 de ConfigMgr 2012 R2 SP1.

La fonctionnalité de mise à jour automatique des clients depuis le ConfigMgr 2012 SP2/ConfigMgr 2012 R2 SP1 apporte une réduction non négligeable d'opérations pour la montée de versions des clients.

Concernant la mise à jour automatique, il n'est pas possible de savoir exactement quand les clients seront mis à jour. Il est possible de spécifier un intervalle de temps en jour pendant lequel les clients se mettront à jours automatiquement.

Exemple pour un choix de 2 jours, les clients recevront leurs instruction (policy) de mise à jour automatique et installeront la mise à jour du client aléatoirement pendant cette période de 2 jours.

Plus il y a de client dans l'infrastructure, plus il est conseillé d'allonger la période de temps afin de ne pas surcharger le réseau et les serveurs System Center Configuration Manager.

Il est possible depuis le SP2 de ne pas mettre à jour les clients sur les serveurs. Cette option peut être utile pour maitriser la mise à jour du client sur les serveurs.

/!\Avertissement/!\

Dans le cas d'une infrastructure avec un serveur CAS et plusieurs sites primaires, Il n'est pas possible d'utiliser cette fonctionnalité uniquement sur un serveur primaire. Cette option fonctionne pour toute la hiérarchie, donc pour tous les clients de tous les sites primaires.

Cependant, si un des site primaire de la hiérarchie n'est pas encore migré dans la même version que le CAS, alors la migration automatique du client rattaché à ce site primaire ne se fera pas.

Cela peut permettre de maitriser, un peu, le déploiement, primaire par primaire. Mais, attention, lors de l'installation d'un Service Pack ou d'un CU, il est recommandé d'installer rapidement le même niveau de mise à jour sur tous les serveurs de la hiérarchie (CAS, Primaire, Secondaire).

Pour plus d'informations sur la mise à jour automatique du client, voir les sites suivants :

• https://technet.microsoft.com/en-us/library/gg712298.aspx
• https://blogs.technet.com/b/configmgrteam/archive/2015/08/04/automatically-updating-the-configuration-manager-client.aspx

Depuis très longtemps, les entreprises qui souhaitaient unifier les réglages utilisés dans leur parc disposaient d’outils industriels dont le plus connu est, sans doute, Microsoft Deployment Toolkit (MDT) et mon préféré est System Center Configuration Manager (ConfigMgr). Ces outils se fondent sur des possibilités, aujourd’hui apportées par le Windows Assessment and Deployment Kit (ADK).

Le point de départ de ces outils peut être un ordinateur équipé ou non d’un système d’exploitation. Ils sont, par conséquent, utilisables si vous partez de systèmes équipés de Windows XP. Selon les outils que vous utilisez, vous pouvez couvrir des scénarios de type Bare metal (c’est à dire à partir d’aucun système déjà présent, à la restriction des problématiques de licence), Wipe and Load/Refresh (vous effacez tout après avoir sauvegardé ou non des données et réglages des utilisateurs et installez un nouveau système d’exploitation ou le même) et Replace (un ancien ordinateur est remplacé par un nouvel ordinateur).

Un certain nombre de constructeurs proposent des services de personnalisation des ordinateurs en usine qui garantissent une homogénéité des réglages. Cette possibilité se fonde sur la fourniture d’une image du système d’exploitation que des outils tels que MDT 2013 Update 1 ou ConfigMgr 2012 SP2/ConfigMgr 2012 R2 SP1 sont capables de générer.

Windows 10 apporte une solution de mise à jour sur place (Upgrade) qui s’applique à partir de Windows 7 dont le fonctionnement est radicalement différents des méthodes de mises à jour des précédentes versions de systèmes d’exploitation. Globalement, l’ensemble des réglages sont conservés, mais sans trainer les scories éventuelles de l’ancien système. Le gain immédiat pour l’utilisateur est qu’il n’a pas besoin de réinstaller toutes les applications déjà présentes dans l’ancien système. Le second gain est la rapidité à laquelle l’opération s’effectue. Cette solution couvre les scénarios de type refresh, replace et, dans une moindre mesure, bare metal.

La solution de la mise à jour n’est pas utilisable dans tous les cas de figure. Par exemple, si vous souhaitez passer d’un système 32 bits à un système 64 bits, mais aussi d’un système avec un BIOS vers UEFI ou, encore, changer de domaine d’appartenance.

MDT 2013 Update 1 et/ou ConfigMgr 2012 SP2/ConfigMgr 2012 R2 SP1 sont les versions minimales nécessaires pour couvrir cette solution.

Avec la multiplication des usages de type Bring Your Own Device (BYOD), il devenait utile de proposer une solution pour personnaliser un ordinateur personnel déjà installé et utilisé et lui apporter le minimum de réglages non négociables pour accéder au système d’information de l’entreprise. Windows 10 apporte la réponse dite du Provisioning. Le point de départ nécessaire pour cette solution est dans le composant Windows Imaging and Configuration Designer (WICD) de l’ADK.

MDT 2013 Update 1 et/ou ConfigMgr 2012 SP1/ConfigMgr 2012 R2 SP2 sont les versions minimales nécessaires pour couvrir cette solution, mais également Microsoft Intune ou un simple fichier envoyé par messagerie électronique, mais là, on sort des solutions complètement industrielles.

Avec l’arrivée des différentes branches que j’ai déjà évoquée ici, Windows 10 propose également la solution dite du Servicing. Outre les services de Windows Update (en mode individuel) ou de WSUS (en mode légèrement plus industriel), ConfigMgr 2012 SP1/ConfigMgr 2012 R2 SP2 sont les versions minimales nécessaires pour couvrir cette solution dès lors que vous ne cherchez pas à changer de branche. Pour, par exemple, passer de Current Branch à Current Branch for Business (CB/CBB), il vous faudra, à minima, la prochaine version de ConfigMgr actuellement en phase de Technology Preview que vous pouvez vous procurer à l’emplacement suivant :
https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-technical-preview

N’hésitez pas à laisser des commentaires si vous souhaitez plus de précisions ou avez besoin d’aide dans ce dédale de solutions !

Cette version supporte les versions suivantes de ConfigMgr :

• System Center 2012 Configuration Manager SP1
• System Center 2012 Configuration Manager SP2
• System Center 2012 R2 Configuration Manager
• System Center 2012 R2 Configuration Manager SP1

Elle supporte la version 1.2 de SCAP qui est, elle-même, compatible avec les versions 1.1 et 1.0.

Pour mémoire, les extensions SCAP permettent de convertir des modèles de sécurité publiées par l’agence gouvernementale américaine du National Institute of Standards and Technology (NIST) en règles de conformité. Elles sont déjà compatibles avec l’outil Security Compliance Manager (SCM) qui est, lui-même, capable de consommer également des modèles SCAP et de les exporter en packs de configuration.

Pour plus d’informations sur le format SCAP, il peut être utile d’aller sur https://scap.nist.gov/.

Si vous souhaitez diverger des modèles de sécurité livrés par Microsoft ou ceux de l’USGCB, il peut être intéressant de lire l'article publié par Aaron MARGOSIS qui a travaillé avec le gouvernement américain à la mise au point de ces modèles standards.

Le positionnement souhaité par Microsoft est que la branche dite “Current Branch” ou CB soit la plus largement utilisée et s’adresse principalement aux marché des particuliers et devrait recevoir des mises à jours apportant de nouvelle fonction à un rythme de l’ordre de 2 à 3 fois par an, en omettant des correctifs cumulatifs, probablement, mensuels.

La branche dite “Current Branch for Business” ou CBB s’adresse, comme son nom l’indique, aux entreprises. Elle ne constitue pas une autre version de Windows, mais donne, simplement, la possibilité de différer de quelques mois la distribution des nouveautés de la branche précédente ; à savoir Current Branch.

Pour des entreprises qui ont des contraintes de régulation, la branche dite “Long Term Servicing Branch” ou LTSB garantit une stabilité dans le temps équivalente à celle rencontrée jusqu’à maintenant dans les évolution de version de Windows ; c’est à dire, probablement, de l’ordre de 3 à 4 ans. Cette branche ne devrait être utilisée que si de réelles contraintes techniques vous empêchent de mettre à jour régulièrement vos systèmes tels que l’on peut le voir, par exemple, dans le monde pharmaceutique, pour une minorité de systèmes.

Je mets de côté, les différentes branches dont la plus connue est “Insider Preview Branch” qui continue d’exister, mais que certains ont pu utiliser avant la sortie de Windows 10 en juillet dernier et qui possède, elle-même, différentes subtilités en fonction de la cadence (slow ou fast), également, de mise à jour. Cette branche n’est pas si confidentielle que cela puisqu’elle a concerné plusieurs millions d’utilisateurs qui, pour certains, continuent à faire partie de cette branche afin de préparer les futures évolutions de Windows.

Pour l’alimentation des mises à jour de chaque branche, différents outils sont disponible, à commencer par le canal habituel de Windows Update qui gère l’ensemble des branches. Windows Update for Business (WUB) est une nouvelle offre destinée à gérer la branche CBB qui pourra également être gérée via Windows Server Update Services (WSUS) et les outils tels que System Center Configuration Manager (ConfigMgr).

Les différentes éditions de Windows supportent les différentes branches du tableau ci-dessous :

	Home	Pro	Enterprise
Current Branch (CB)
Current Branch for Business (CBB)
Long Term Servicing Branch (LTSB)

Pour mémoire, seules les édition Home et Pro sont disponibles en OEM, c’est à dire installées directement en usine.

Pour les ordinateurs équipés d’une version de Windows antérieure à Windows 7, Windows 10 peut être acheté dans le commerce ou via Internet.

Pour les entreprises disposant d’un contrat de licence en volume, les édition Pro et Enterprise sont disponibles sur le portail MVLS. La mise à jour est gratuite vers les éditions Home et Pro en fonction des éditions précédentes de Windows déjà présentes.

Le passage d’une branche à l’autre n’est pas toujours faisable :

• de LTSB vers CB, par une mise à jour sur place.
• de CB vers LTSB, uniquement en reformatant, car c’est assimilé à un retour en arrière.
• de CB vers CBB, à travers une clé de registre.

Le passage de Pro à Entreprise reste faisable comme c’était déjà le cas dans les versions précédentes de Windows.

Un dernier point par rapport à la gestion des cycles de mise à jour, seules les versions récentes de Microsoft Deployment Toolkit (MDT), ConfigMgr et Microsoft Intune seront capables de les supporter ; c’est à dire, précisément, MDT 2013 Update 1 et pour ConfigMgr, uniquement la version qui, pour l’instant est en Technical Preview et que vous pouvez vous procurer à l’emplacement suivant :
https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-technical-preview