PI Services

Bonjour dans le cadre de la mise à jour des correctifs pour Windows 2012

il se peut que vous rencontriez une erreur 8024401F.

IMAGE DE L’ERREUR:

Etape 1 : Il faut arrêter le service de mise à jour en tapant la command ci-dessous , ATTENTION il faut être en mode Administrateur.

Etape 2 : Il faut renommer le répertoire C:\Windows\Softwaredistribution en Softwaredistribution–old.

Etape 3 : Il faut redémarrer le service de mise à jour en tapant la command ci-dessous , ATTENTION il faut être en mode Administrateur.

Etape 4 : Il faut relance la mise à jour

Vous souhaitez modifier les propriétés générale de la ressource cluster DHCP server en Powershell.

Récupérer dans 3 variables les Paths que vous voulez définir pour :

• Database path
• Audit file path
• Backup path

$DatabasePath="j:\dhcp\db"
$AuditFilePath="j:\dhcp\logs"
$BackupPath="j:\dhcp\backup"

Récupérer maintenant votre ressource de type DHCP Service
$RessDHCP=get-ClusterResource "DHCP Server"

Nous allons maintenant manipuler des instances basées sur Microsoft.FailoverClusters.PowerShell.ClusterParameter qui va nous permettre de manipuler nos propriétés.

Modification du Database Path
$param1 = New-Object Microsoft.FailoverClusters.PowerShell.ClusterParameter $RessDHCP,DatabasePath,$DatabasePath

$param1 | Set-ClusterParameter

Modification de l'Audit File Path
$param2 = New-Object Microsoft.FailoverClusters.PowerShell.ClusterParameter $RessDHCP,LogFilePath,$AuditFilePath

$param2 | Set-ClusterParameter

Modification du Backup path
$param3 = New-Object Microsoft.FailoverClusters.PowerShell.ClusterParameter $RessDHCP,BackupPath,$BackupPath

$param3 | Set-ClusterParameter

Les propriétés sont maintenant définis.

Introduction

• Partie 1 : introduction et syntaxe
• Partie 2 : configuration du mode push
• Partie 3 : configuration du mode pull (via smb)
• Partie 4 : configuration du mode pull (via web service)
• Partie 5 : création d’une ressource personnalisée

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Windows 2012/8 et Windows 2008 R2/7.

Lors du précédent article nous avons vu l'implémentation du mode Pull via un web service.

Desired State Configuration est fourni avec un certain nombre de ressources. Malgré qu'il y en ai peu, et comme évoqué dans le précédent article, Microsoft et la communauté se sont employés à créer des nouvelles ressources. Dans cette cinquième et dernière partie, nous évoquerons la création d’une ressource personnalisée. Cette dernière permettra de prendre en charge un scénario non présent dans les ressources existantes : la présence d'un partage NFS.

Fonctionnement

• Un fichier .SCHEMA.MOF contenant sa définition et plus particulièrement toutes les propriétés que l'on pourra renseigner.
• Un module Powershell contenant quelques fonctions obligatoires (.PSM1)
• Un fichier .PSD1 représentant le manifest du module Powershell. Ce dernier contiendra les fonctions a exporter de notre module. Ce dernier est principalement utilisé pour versionner le module et avoir quelques informations dessus.

Le module Powershell doit obligatoirement comporter trois fonctions. Elles seront appelées lorsqu'un fichier de configuration contiendra une ressource du type que l'on aura créé. “Get-TargetResource” permet de récupérer la configuration telle qu'elle a été définie. “Set-TargetResource” applique une configuration (création, modification et suppression) et “Test-TargetResource” effectue le test de validité (elle retourne un booléen).

Il convient à la personne créant le module de développer le corps de ces fonctions (le squelette étant toujours identique), c'est à dire les paramètres et les process effectués.

Pré-requis

Au lancement de Powershell 4.0, il pouvait être fastidieux de développer ses propres ressources car il fallait respecter une certaine syntaxe. Cependant, Microsoft a développé un module permettant de faciliter la création de ressource à destination de DSC : xDscResourceDesigner. Ce dernier va nous permettre de générer nos fichiers automatiquement. Il est disponible en suivant le lien ci-dessous : http://gallery.technet.microsoft.com/scriptcenter/xDscResourceDesigne-Module-22eddb29

Il suffit ensuite de placer ce module dans le dossier :
“C:\Program Files\WindowsPowerShell\Modules”.

Création de la ressource

Pour créer la ressource, on commence par définir ses propriétés avec la cmdlet “New-xDscResourceProperty”. Celles-ci possèdent à minima un nom, un type et des attributs. Ces derniers permettent de définir l'accessibilité (lecture, écriture,...). Lorsque l'on définit une nouvelle ressource, au moins une de ses propriétés devra posséder l'attribut “Key” et ne pourra être un tableau. Cet attribut permet d'indiquer la propriété utilisée lors de la recherche d'une ressource.

• le nom du partage
• le chemin vers lequel le partage pointe
• la présence ou l'abscence du partage

Un module Powershell qui ne comprend pour l'instant que le fichier .PSM1 a aussi été généré. Il faut maintenant définir la logique de nos 3 fonctions à l'intérieur de ce module.

Get-TargetResource

Set-TargetRessource

NB : Lors de la génération du template de module à remplir, il est indiqué dans le corps de la fonction qu'il faut positionné la variable globale “$global:DSCMachineStatus” avec la valeur 1 si une configuration nécessite un reboot après son application.

Test-TargetResource

A noter, qu'à la fin de notre module, la cmdlet “Export-ModuleMember” est présente et obligatoire afin que Powershell découvre correctement les méthodes de la ressource.

Génération du manifest

Les autres champs du fichier .PSD1 généré peuvent aussi être spécifiés via la cmdlet précédente ou en remplissant manuellement le fichier (via un éditeur de texte). Certaines propriétés seront même automatiquement remplies (exemple : auteur avec le samaccountname de l'utilisateur ayant lancé la commande).

Voici un lien menant vers le manifest généré pour cette ressource : Manifest

Import de la ressource et utilisation

Il suffit de placer notre ressource (Répertoire C:\NFSShare dans notre exemple) dans “C:\Program Files\WindowsPowerShell\Modules\”

 

Conclusion

Lors de cet article, nous avons vu la création d'une ressource permettant de gérer des partages NFS. Il est possible de l'améliorer en gérant d'autres propriétés de ce type de partage comme les permissions. 

Vous souhaitez créer en ligne de commande un groupe de ressource Cluster.

Pour cela, il faut utiliser la ligne de commande suivante :

([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup(“NomDuGroupe”, XXX)

Ou XXX représente l’identifiant du groupe de ressource que vous voulez créer.

Par exemple : pour créer un groupe de ressource Hyper-V réplica Broker, vous devez saisir l’ID 115 soit :

([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup(“NomDuGroupe”, 115)

Maintenant, pour créer un groupe de ressource DHCP Cluster, l’identifiant correspondant est le 102 soit :

([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup(“NomDuGroupe”, 102)

Ci-dessous, une capture d’écran qui vous donnera l’ID associé à un type de groupe de ressource Cluster.

Introduction

Après le Management Framework 4.0 qui apportait Desired State Configuration, la Powershell Team vient de publier Management Framework 5.0 Preview (le 03/04/2014). Cette nouvelle version intervient seulement 6 mois après la sortie de la V4.0. Microsoft accélère son cycle de développement avec des versions contenant moins de nouveautés mais celles-ci restent tout de même importantes.

Le Management Framework 5.0 est pour l'instant compatible uniquement avec Windows Server 2012 R2, Windows 8.1 Pro et Enterprise mais Microsoft parle d'une rétrocompatibilité avec d'autres versions à venir.

Voici le lien vers l'update a installé :
http://www.microsoft.com/en-us/download/details.aspx?id=42316

Il contient Powershell V5.0 et Powershell ISE.

Il est temps de faire le tour des nouveautés !

Générales

Comme à chaque nouvelle version de Powershell, on nous annonce moins de bugs, de meilleures performances et des nouvelles Cmdlets.

Desired State Configuration

Des corrections de bug et des améliorations de performances sont au programme. La Team Powershell indique que Desired State Configuration est une technologie importante pour eux. C'est logique quand on voit le nombre de ressources (plus de 50) qui a été développé depuis la sortie de Powershell V4.0 : http://blogs.msdn.com/b/powershell/archive/2014/03/28/dsc-resource-kit-wave-3.aspx . Ils indiquent que la stratégie de Microsoft est de pousser l'intégration de DSC avec les outils de gestion de configuration (SCCM ?) et que lors d'un choix de ce type de solution, il sera important qu'elle soit compatible avec DSC.

Switch

Powershell V5.0 propose un module natif permettant de manipuler ses switchs. Microsoft a travaillé avec les leaders de l'industrie afin d'élaborer un standard. Les équipements compatibles porteront la certification "Certified for Windows". Au delà de Powershell, ce standard est utilisé dans SCVMM 2012. Cette technologie fait partie de la politique "Datacenter Abstraction Layer" de Microsoft. Elle vise à gérer l'intégralité d'un Datacenter via un même outil de management au lieu d'avoir une vision réduite à un équipement. Elle permettra d'éviter la multiplication des outils de gestion.

Le module qui permet de manipuler les switchs est : NetworkSwitch. Pour être compatible avec ce standard, le switch devra supporté les sessions distantes CIM. Pour rappel, c'est un standard ouvert développé par la DMTF (Distributed Management Task Force) qui définit les interractions entre des équipements ainsi que leur gestion, supervision, etc sous la forme d'un schéma. Ce schéma est orienté objet. WMI est notamment compatible avec ce standard (depuis Powershell V3.0 via les Cmdlets comme Get-CIMClass, Set-CIMInstance, ...).

Voici la liste des commandes de ce module :

Parmi les fonctionnalités, il est ainsi possible de :

• réaliser la configuration générale du switch : nom d’hôte, bannière, activation/désactivation de fonctionnalités
• gérer les vlan : création, suppression, activation, désactivation, listing
• configurer les ports : activation, désactivation, listing, définition des propriétés

OneGet

On termine ce tour des nouveautés, avec la fonctionnalité qui va sans doute faire le plus parlée d'elle : OneGet. C'est tout simplement un gestionnaire de paquet comme on peut en rencontrer sur Unix !

Pour obtenir la liste des commandes disponibles :

On peut utiliser la commande Find-Package pour chercher 7zip par exemple :

Puis-on l'installe (Install-Package) :

Bien entendu, comme tout gestionnaire de paquet, il s’occupe également d’installer automatiquement les dépendances.

La commande Get-Package permet de récupérer les packages déjà installé. Le package apparaît dorénavant dans le Start Screen (ou dans Program Files) comme n’importe quel autre programme :

Dans cette version preview, OneGet ne possède qu'une seule source (ou repository) : Chocolatey (https://chocolatey.org/packages) qui contient actuellement plus de 1700 package. Ce dernier est basé sur NuGet (connu des utilisateurs de Visual Studio) qui est justement un gestionnaire de package. Microsoft ajoutera le support d'autres repositories ultérieurement. On peut même imaginer qu'il sera possible de créer sa propre source et de l'ajouter via la commande Add-PackageSource. Certaines personnes ont d'ailleurs déjà commencé à le faire : http://learn-powershell.net/2014/04/11/setting-up-a-nuget-feed-for-use-with-oneget/.

Contexte

L’intégration d’un poste à un domaine Active Directory nécessite un contrôleur de domaine “writable”. Dans le cas où les postes se trouvent avec le RODC dans un site local et que les DC sont dans un site central (via un MPLS sans filtrage réseau par exmple) l’intégration au domaine fonctionne normalement.

Mais dans le cas où le RODC est dans une DMZ (ou un réseau isolé) qui bloque les flux AD depuis le poste vers le DC “writable” il est alors impossible d’ajouter le poste de façon classique au domaine.

Solution

L’ajout du poste à travers le RODC se fait en quatre étapes.

1ère étape :

Il est tout d’abord nécessaire de créer le compte ordinateur sur un DC en lui spécifiant un mot de passe. Pour cela utiliser la commande PowerShell suivante :

1: New-ADComputer -Name <Nom du poste> -AccountPassword (Read-Host -AsSecureString "Password?") -SAMAccountName <Nom du poste> -Enabled $true

2ème étape :

Ensuite il faut ajouter le poste dans un groupe qui est autorisé à répliquer les mots de passe avec le RODC (par défaut le groupe Allow RODC Password Replication Group).

3ème étape :

Sur le compte ordinateur du RODC, Propriétés et dans l’onglet Password Replication Policy, cliquer sur Advanced... Ensuite cliquer sur Prepopulate Passwords… et ajouter le compte ordinateur du poste.

Il faut maintenant attendre que la réplication se fasse entre le DC et le RODC.

4ème étape :

Il faut maintenant lancer le script disponible à cette adresse http://technet.microsoft.com/fr-fr/library/dd728035(v=ws.10).aspx en indiquant les paramètres suivant :

1: joinscript.vbs /domain <nom du domaine > user <utilisateur> password <mot de passe> /dc <FQDN du RODC> /readonly /machinepassword <mot de passe du compte ordinateur> 

Une fois le script terminé, il faut redémarrer le poste. Au redémarrage il sera intégré au domaine.

Contexte

Lors de la modification d’un objet dans l’Active Directory (exemple : modification sur l’objet KRBTGT lors de l’installation d’un RODC), le Domain Controller redémarre automatiquement de manière inopinée et non planifiée avec ce message d’erreur :

A la suite du redémarre, les erreurs suivantes se trouvent dans l’Event Viewer :

Application – Wininit – Error 1015 : A critical system process, C:\Windows\system32\lsass.exe, failed with the status code c00000005. The machine must now be restarted.

Application – Application Error – Error 1000 : Faulting application name: lsass.exe

Cause

L’erreur est due à un paramètre de l’Audit object access. Ce problème est vraisemblablement un bug de Windows Server 2012 R2.

Solution

Pour résoudre ce problème, il faut désactiver (ou a minima de ne pas inspecter) la journalisation des accès aux objets dans le Local Security Group ou dans une GPO.

Ce paramètre se trouve dans Computer Configuration, Policies, Windows Settings, Security Settings, Local policies, Audit Policy.

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

• Partie 1 : introduction et syntaxe
• Partie 2 : configuration du mode push
• Partie 3 : configuration du mode pull (via smb)
• Partie 4 : configuration du mode pull (via web service)
• Partie 5 : création d’une ressource personnalisée

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Winsows 2012/8 et Windows 2008 R2/7.

Après avoir montré la configuration du mode Push, cette troisième partie est consacrée au mode Pull et plus particulièrement lorsqu'on l'utilise conjointement à un partage de fichier Samba.

Ainsi, j'expliquerai comment fonctionne le mode Pull ainsi que les différentes étapes de configuration.

Fonctionnement

Pour rappel, DSC fonctionne de la manière suivante :

• Récupération de la configuration
• Application de la configuration
  

Ces deux étapes se répètent indéfiniment selon le temps d'actualisation qui a été défini pour chacune d'entre elles.

La principale différence entre les modes Pull et Push concerne la récupération de la configuration. Le mode Pull utilise le principe inverse du mode Push. Au lieu de transmettre les modifications de configurations à nos serveurs, ces derniers vont interroger eux-même un "dépôt" central (appelé serveur Pull) qui contiendra l'ensemble des configurations gérées par DSC. Le serveur appliquant sa configuration et donc aussi à l'origine de la connexion pour vérifier s'il y a une nouvelle version de sa configuration. Lors de la récupération d'une nouvelle version, le fichier MOF récupéré est vérifié via un fichier checksum présent sur serveur Pull. Ci-dessous un schéma récapitulatif des deux modes (Pull et Push) :

En mode Pull, nous n'avons plus à nous préoccuper de savoir si un de nos serveurs possède la bonne configuration (si elle lui a bien été transmise). Concernant le mode Pull, il existe actuellement deux types de dépôts pour centraliser les fichiers de configurations :

• Un partage de fichier (expliqué dans cet article)
• Un web service (son fonctionnement sera détaillé dans la partie 4 de ce guide sur DSC).

Ceux-ci seront interrogés par les serveurs utilisant DSC.

Comme pour le mode Push, il est nécessaire de configurer la ressource LocalConfigurationManager qui définira les différents paramètres de fonctionnement de DSC sur les machines clientes.
L'un des principaux paramètres configuré est le ConfigurationId. Il s'agit d'un GUID utilisé pour reconnaître le bon fichier de configuration à télécharger depuis le serveur Pull. Ce GUID est inscrit dans le nom du fichier de configuration (exemple : 6c7544f9-4fa9-4a62-a715-04aebfd70b85.mof).

La configuration du mode Pull s'effectue en différentes étapes :

• Configuration de la ressource LocalConfigurationManager. Un fichier .meta.mof est créé par serveur pour appliqué la nouvelle configuration de la ressource sur chaque serveur.
• Génération des fichiers de configuration des serveurs : il s'agit des fichiers .MOF contenant les configurations des serveurs utilisant DSC (un fichier par serveur).
• Copie des fichiers sur le partage (serveur Pull).
• Renommage des fichiers MOF avec le GUID de chaque machine concerné.
• Création des fichiers checksums afin de vérifier l'intégrité des fichiers MOF lors de la récupération d'une configuration par un client (fichier .mof.checksum).

Dans la suite de cet article, je fournis des scripts pour automatiser l'ensemble de ces étapes. Certaines fonctions sont inspirés par l'article de Johan Akerström (http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/) sur le sujet. Les scripts présents en fin d’article sont compatibles avec Windows 7/2008R2 car ils n'utilisent pas les nouvelles Cmdlet Powershell 3.0 et 4.0 uniquement disponibles sur Windows 8/2012 et supérieur. Cela permet de mettre en place un environnement DSC sur une infrastructure ne possédant pas les toutes dernières version des systèmes d'exploitation Microsoft. Avec ces scripts, il est possible de déployer un serveur Pull via DSC, d'automatiser la configuration de DSC sur les serveurs à gérer ainsi que la génération des fichiers de configuration.

Ressource LocalConfigurationManager

La ressource LocalConfigurationManager est expliquée dans la Partie 2 ; je vous invite donc à vous y référer en complément des paramètres liés au mode Pull.

• RefreshMode : C’est le mode de fonctionnement du client DSC, la valeur attendue est Pull (pour que cela soit fonctionnel les paramètres DownloadManager et DownloadManagerCustomData sont obligatoire)
• DownloadManager : Les valeurs possibles sont WebDownloadManager ou DSCFileDownloadManager. Lorsque l'on utilise le mode Pull en mode fichiers (et non web service) alors il faut choisir DSCFileDownloadManager.
• DownloadManagerCustomData : Il s'agit ici d'indiquer dans un hashtable (via la clé SourcePath), le chemin d'accès aux fichiers MOF.
• RefreshFrequencyMins : C'est le temps de refresh du fichier de config à partir de la source (ici SMB)).
• ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
• ConfigurationId : Un GUID pour récupérer les bons fichiers de configurations. La machine n'appliquera que le .MOF portant son ConfigurationID.
• RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.
• ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect (voir partie 2 pour l'explication).

Exemple de reconfiguration du LocalConfigurationManager pour le mode Pull via partage SMB :

NB : Pour appliquer cette configuration, le remote Powershell doit être activé sur les machines clientes (actif par défaut sur Windows 2012/R2)

Partage SMB

Le partage SMB est crucial car il contiendra l'intégralité des fichiers MOF et des fichiers checksums. A partir de Windows 8/2012 est supérieur, il existe un module permettant de gérer simplement les partages SMB (création avec New-SMBShare). Voici une méthode en WMI pour les postes n'ayant pas ce module. Cette dernière ajoute aussi les permissions de partage de contrôle total pour le groupe Everyone.

Ensuite, il est nécessaire d'appliquer des permissions NTFS en lecture et exécution pour le groupe Everyone :

ConfigurationID

Le GUID attendu par le paramètre ConfigurationId peut être généré automatiquement :

On peut aussi utiliser le GUID de l'ordinateur dans Active Directory comme l'explique Johan Akerström dans son article sur DSC : http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/

# Define Get Computer GUID Function 
# Credit: Johan Åkerström 
# http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/
 
Function Get-ComputerGuid { 
  param( 
    [Parameter(Mandatory=$true)] 
    [string]$ComputerName 
  ) 
 
  process { 
    ([guid]([adsisearcher]"(samaccountname=$ComputerName`$)").FindOne().Properties["objectguid"][0]).Guid 
  } 
} 

On peut ensuite copier tous nos fichiers MOF de configuration sur le partage en changeant leurs noms avec le GUID.

Checksum des fichiers MOF

Depuis Powershell 4, il existe une cmdlet permettant de généré un hash : "Get-FileHash". L'algorithme à choisir est SHA256 (celui par défaut).Voici le lien vers la documentation :
http://technet.microsoft.com/en-us/library/dn520872.aspx

Il nous suffit ensuite de créer les fichiers checksum contenant ce hash.

Scripts

Deux scripts sont accessibles via les liens ci-dessous.

Configuration du serveur Pull avec DSC : ici

Librairie de fonctions nécessaires au serveur Pull : ici

L'outil permet de déployer un serveur DSC en mode PULL via DSC. Toutes les étapes sont automatisées. Les fichiers de configurations des clients sont automatiquement générés (copy et renommage avec le guid, création des fichiers checksum, création de tous les fichiers .meta.mof contenant la configuration du LocalConfigurationManager avec la commande Set-DSCLocalConfigurationManager). Il n'y a plus qu'à déployer les ressources LocalConfigurationManager sur les clients (avec un compte possédant les droits nécessaires). Voici les différentes étapes réalisées par le script par ordre d’exécution (chacune d’entre elles nécessite la réussite de la précédente via le paramètre de ressource DSC  DependsOn) :

1. Un dossier contenant le partage avec les configurations est créé.
2. La permission NTFS "ReadAndExecute" est ajouté au group everyone ainsi que la permission "FullControl" pour le compte ordinateur du serveur Pull. En effet, il va créer des dossiers et générer des fichiers. C'est ce compte qui exécute les fichiers de configuration dans DSC.
3. Un partage est généré.
4. Sur ce partage, le groupe everyone possède la permission "Change". Le compte ordinateur du serveur Pull a des droits "FullControl".
5. Une arborescence de dossier est généré :
       Il y a un dossier contenant les configurations créées par l'administrateur (OriginalConfiguration). Un second répertoire (Configuration) a les même configurations renommées avec le GUID de l'ordinateur (pré requis du mode Pull pour que le client récupère sa configuration, voir explication sur le ConfigurationId). Ce dernier contient aussi un fichier checksum pour chaque fichier de configuration .MOF. Un script de librairie est présent dans un troisième dossier (Scripts). Enfin, un répertoire nommé LCM possède tous les fichiers ".meta.mof" de configuration de la ressource LocalConfigurationManager des machines clients.
6. Le script Powershell contenant les fonctions suivantes est copié dans le répertoire des scripts du serveur Pull :
   • Récupération d'ordinateurs sans module Active Directory (via adsisearcher)
   • Génération automatique des fichiers checksum à partir d'un fichier .MOF
   • Récupération du GUID d'un ordinateur
   • Configuration de la ressource LocalConfigurationManager
7. Les fichiers de configuration de la ressource LocalConfigurationManager sont générées pour chaque machine client via le filtre qui a été convenu. Il est possible de sélectionner des ordinateurs par unité d'organisation ou par groupe Active Directory suivant les paramètres entrées lors de la génération du fichier de configuration MOF du serveur Pull.
8. Copie des fichiers de configurations créer par l'utilisateur sur le répertoire contenant les .MOF renommés avec un GUID ; ainsi que création des fichiers checksum associés pour que les clients vérifient l'intégrité de la configuration récupérée. Gràce à cette étape dès qu'une nouvelle configuration ou une modification de l'une d'entre elles a lieu, elle est automatiquement mis à jour avec un une regénération du fichier checksum.

Les étapes 1,2,3,4,5,7,8 sont des ressources DSC de types "script" tandis que l'étape 6 est de type "file".

NB : DSC possède son propre journal d'événements pour vérifier son bon fonctionnement : Applications and Services Logs / Microsoft / Windows Desired State Configuration. Ce dernier permet de superviser DSC lorsqu’on ne déploie plus les configurations manuellement (en mode Push).

Introduction

Depuis la sortie d’Exchange 2013, le rôle n’avait pas été porté dans cette nouvelle version d’Exchange. Ce qui oblige les entreprises à faire l’upgrade vers Exchange 2013 en conservant les serveurs Exchange Edge en version 2010. Pour rappel, le rôle Edge est apparu avec Exchange 2007.

Depuis février 2014, Microsoft à publier le SP1 d’Exchange 2013 et réintroduit le rôle Edge ! Vous allez maintenant pouvoir mettre à jour vos infrastructures.

Pour rappel, la principale fonctionnalité du rôle Edge est de protéger votre infrastructure de messagerie des spam et virus grâce aux différents agents présent sur le serveur Edge.

Il faut noter qu’avec la version 2013 d’Exchange, la console Exchange de management telle qu’on la connaissait avec Exchange 2010, n’existe plus. La console est remplacée par le portail web ECP. Ce portail n’existe pas sur le serveur Edge. Un serveur Edge 2013 devra donc être administrer uniquement en PowerShell.

Installation

Sur le serveur Edge, quand vous exécutez l’installation, vous pouvez maintenant choisir le rôle Edge. Les outils de gestion s’installent automatiquement ainsi que les prérequis.

Installation et configuration

Voici le lien de téléchargement du service pack 1 : http://www.microsoft.com/en-us/download/details.aspx?id=41994.

Une fois que le rôle est installé et le serveur redémarré, vous devez effectuer deux actions : Installer la clé du produit et faire l’abonnement Edge (il est possible de se passer de cette étape)

Installation de la clé produit :

Sur le serveur Edge, dans la console Exchange Management Shell, saisir la cmdlet :

Set-ExchangeServer <NomDuEdge> –ProductKey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

Pour vérifier l’application de la clé, on peut lancer la cmdlet : Get-ExchangeServer

Créer l’abonnement Edge vers vos serveurs Exchange 2013 :

Sur le serveur Edge, dans la console Exchange Management Shell, saisir la cmdlet :

New-EdgeSubscription -FileName "C:\EdgeSubscriptionInfo.xml"

Sur un serveur Exchange, dans une console Exchange Management Shell, après avoir copié le fichier XML issu du serveur Edge :

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeSubscriptionInfo.xml" -Encoding Byte -ReadCount 0)) -Site "Default-First-Site"

Maintenant que le serveur Edge est en place, il faut le configurer, voici les principales commandes qui vont vous intéresser :

• Get-IPBlockListProvidersConfig – Pour spécifier un fournisseur de blacklist
• Get-SenderFilterConfig – Pour bloquer des expéditeurs
• Get-RecipientFilterConfig – Bloquer des destinataires
• Get-ContentFilterConfig – Bloquer du contenu dans les mails

Je vous laisse le soin d’aller voir sur Technet (http://technet.microsoft.com/en-us/library/jj218660(v=exchg.150).aspx) pour savoir comment utiliser ces cmdlets et en découvrir bien d’autres.

Conclusion

Grâce à ce service pack 1 d’Exchange 2013, vous pouvez mettre à jour votre serveur Edge vers la dernière version de manière à avoir un niveau de version homogène.

Nous pouvons vous accompagner dans la mise à jour de votre infrastructure de messagerie Exchange, n’hésitez pas à nous consulter pour un éventuel projet.

Contexte

Dans le cadre de projets, il peut arriver que les licences définitives ne soient pas livrées au moment du déploiement des serveurs. Pour ne pas perdre de temps, il est possible d’installer la version d’évaluation de Windows Server 2012 R2 (http://technet.microsoft.com/fr-fr/evalcenter/dn205286.aspx) qui est valable 180 jours et de la mettre à niveau vers une version commerciale une fois la licence acquise.

Solution

La commande-let DISM permet de mettre à niveau notre version d’évaluation vers une version commerciale (avec licence).

Pour se faire, lancez l’invite de commande en tant qu’administrateur et tapez la commande suivante :

DISM /Online /Set-Edition:<type de version> /ProductKey:<licence> /AcceptEula

Une fois la commande terminée, il faut redémarrer le serveur.

Remarque : Afin de savoir vers quelle type de version il est possible de mettre à niveau le serveur utilisez la commande DISM /Online /Get-TargetEditions

Après le redémarrage le serveur n’est plus un serveur d’évaluation et il peut être activé normalement.

Remarques

1 – Cette commande fonctionne également avec une des nouveautés de Windows Server 2012 R2 : l’AVMA (Automatic Virtual Machine Activation).

2 – Attention cette mise à niveau ne fonctionne pas si le serveur est un contrôleur de domaine. Pensez donc bien à faire la manipulation avant l’installation du rôle Active Directory Domain Services !