Le blog technique

La mise en œuvre complète des prérequis de configuration et d’installation pour configuration manager a toujours été délicate et longue. Avec SCCM 2012, cela ne s’est pas arrangé…

“ConfigMgr 2012 R2 Prerequisites Installation Tool 1.3.0”  est donc le bienvenu pour aider sur une installation en maquette,  un petit site ou pourquoi pas en guise d’outil de contrôle, puisqu’il affiche les prérequis manquants.

Il est applicable à Windows Server 2012 et Windows Server 2012R2 et pour SCCM 2012 (comme son nom l’indique)…

Mieux vaut le lancer via une consoles powershell en mode administrateur.

Les Onglet “Central Administration Site”, “Primary Site” et “Secondary Site” permettent d’installer les prérequis pour l’installation des composants de base pour ces types de sites.

[Mais bon… lorsqu’on met en place un CAS c’est pour faire face à une grosse infrastructure et dans ce cas est ce vraiment une bonne idée de passer par un outil qu’on ne contrôle pas… ]

Ci-dessous le type de retour pour un site primaire. On constate que lorsque les composants sont déjà disponibles, le label “Verified installed” s’affiche.

On remarque le bouton “Download prerequisites files” qui permet de récupérer en avance de phase les fameux fichiers de prérequis demandé pendant l’installation de SCCM ( depuis SCCM 2012 ).

Les prérequis pour l’installation au choix des rôles MP, DP, Catalogue d’application ou Point d’enrollement ( pour les MACs ) peuvent être sélectionnés  dans l’onglet “Site System Roles”.

Et dans l’onglet Other, on peut carrément installer WSUS ( pour le SUP ) et ADK (avec les composants requis pour l’OSD uniquement).

On peut aussi lancer les prérequis AD. Pour l’extension du schémas, un accès au media SCCM2012 R2 est demandé pour exécuter Extadsch.exe.

Et voilà.
Il manque encore la configuration de SQL mais là c’est trop demandé vu le nombre de configurations possibles.

Lors de la mise en œuvre d’une réplication entre deux serveurs standalone en mode non compressé, la réplication se met en échec après 500Go de données copiés.

Les eventID 33680,32086 et 32022 sont générés dans le journal Microsoft\Windows\Hyper-V-VMMS\Admin

C’est un bug. L’équipe produit Microsoft étant désormais informée du problème, un hotfix devrait être produit.

En attendant on peut relancer la réplication jusqu’à ce que la réplication initiale aboutisse, par tranche de 500Go.

Il est possible de le faire manuellement via la console Hyper-V, pour des petits volumes et sur un petit nombre  de réplicas.

Dans le cas contraire il faut mettre en place une tache planifiée qui relance la réplication initiale chaque fois que l’un des EventID indiqué plus haut se produit.

Le corps du script  a exécuter est le suivant :

#Récupération de la liste des VMs en échec

$VmSEnEchec = Get-VMReplication | ?{$_.state –eq “Error”} |?{$_.Health –eq “Critical”}

#Relance des réplications

ForEach($VmEnEchec in $VmSEnEchec ) {Resume-VMReplication –VMName $VmEnEchec.Name}

Avec l’arrivée de Powershell, Microsoft avait imaginé un moyen de signaler aux administrateurs les fichiers ps1 provenant de l’extérieur.

Les scripts powershell peuvent être “zonés” par certaines applications complices ( = exécutant Attachment Execution Service ) qui sont amenées à gérer des flux réseau. Internet Explorer était de celles là …

Il y a 6 types de zone :

NoZone = -1,
MyComputer = 0,
Intranet = 1,
Trusted = 2,
Internet = 3,
Untrusted = 4

Si votre script est passé par l’une d’entre elle et qu’il s’est vu attribué un 3 ou plus, pas de chance, il faut le dézoner ou changer  l’execution policy de votre poste, utilisateur ou process.

L’édition et la modification de l’en tête zone.identifier peut se faire via Notepad.
1 – Lancer une fenêtre de commande en tant qu’administrateur.

2- Entrer la commande : notepad “NomDuscriptPowershell.ps1:Zone.Identifier”

3 – Modifier la valeur de ZoneID (=2) puis quitter notepad en sauvegardant.