PI Services

Le blog des collaborateurs de PI Services

Réplication DFS-R & contraintes d’utilisation

Contexte

Lors de l’utilisation d’un partage réseau, les utilisateurs on souvent l’habitude de travailler directement sur les fichiers partagés.

Afin d’éviter toute corruption des données, un système de verrouillage est utilisé, il garantie que seul un unique utilisateur n’édite le fichier. Ce système fonctionne avec les fichiers temporaire/propriétaire.

Voici les étapes d’ouverture et d’enregistrement pour un fichier Word :

1. A l’ouverture du fichier, Word crée un fichier temporaire où les modifications seront enregistrés. Si un autre utilisateur tente de modifier le fichier, le message d’erreur suivant lui apparait :

Ce fichier est déjà ouvert par <nom_utilisateur>. Souhaitez-vous en faire une copie ?

2.  Lors de l’enregistrement du fichier, Word supprime la version d’origine, et la remplace par le fichier temporaire qu’il a renommé comme le fichier d’origine.

Ainsi, plusieurs utilisateurs auront accès au même fichier sans que celui-ci ne soit corrompu.

Contraintes en mode répliqué

Dans le cas d’un partage de fichiers répliqué, l’intégrité des fichiers n’est plus assurée.

Prenons le scénario suivant :

image

Dans ce cas de figure les utilisateurs sont redirigés depuis le namespace vers l’un des deux serveurs de données. En fonction de l’ordre “Refferal Ordering” qui par défaut dirige les clients entre les deux serveurs de manière égale.

Or si un utilisateur modifie le fichier work.docx sur le serveur FILE01, le serveur FILE02 n’en seras pas avisé (la fonction de verrouillage de fichier étant locale) et un autre utilisateur seras en mesure de modifier le même fichier causant une perte d’intégrité où le dernier fichier enregistré sera celui gardé par les deux serveurs.

Afin d’éviter ce type de comportement dangereux, il est possible de modifier le fonctionnement des deux serveurs, tout en gardant un minimum de répartition de charge.

Contournement

Imaginons que les serveurs FILE01 et FILE02 hébergent chacun deux fichiers répliqués indépendamment, Commerce et Administratif.

La première chose à faire est de forcer les clients à n’accéder qu’à un seul des deux serveurs, le serveur secondaire seras utilisé dans le cas où le premier venait à ne plus fonctionner.

Pour ce faire il faut dans la partie “Folder Targets” du namespace Commerce choisir le dossier hébergé par le serveur secondaire (FILE02), ouvrir la fenêtre des propriété puis choisir l’onglet “Advanced” et affecter à ce dossier la priorité “Last among all targets” :

image

Ainsi les utilisateurs souhaitant accéder au partage Commerce, seront toujours dirigé vers FILE01 en priorité.

On peut également aller plus loin et interdire la modification des fichiers sur l’un des serveurs le rendant membre “Read-Only”. La réplication ne fonctionneras alors que dans un sens et le serveur Read-Only, comme son nom l’indique ne pourras qu’afficher les fichiers hébergé en lecture seule.

Pour appliquer le Read-Only sur le serveur secondaire, choisir dans la partie “Replication” le lien de réplication, et dans l’onglet “Membership” sélectionner le serveur membre secondaire comme ceci :

image

Conclusion

A l’aide de ce contournement les utilisateurs Administratif utiliserons un serveurs tandis que les utilisateurs Commerciaux en utiliseront un autre.

Les deux serveurs sont malgré tout répliqués donc en cas de défaillance de l’un, l’autre pourras prendre le relais, cependant, il ne faut pas oublier – en cas de défaillance du serveur principal – de retirer l’option “Read-Only” si celle-ci a été mise en place.

Lync Server 2013 – Mise en place de statuts personnalisés

Contexte

Lync Server 2013 propose différents statuts par défaut pour son client (disponible, occupé(e), de retour dans quelques minutes…). Afin d’améliorer l’expérience utilisateur, il est possible d’ajouter des statuts personnalisés.

Ces statuts se basent sur un fichier XML. Il est possible d’ajouter au maximum quatre statuts personnalisés, d’une longueur maximale de 64 caractères.

Création et syntaxe du fichier XML

Le fichier XML doit se trouver à l’emplacement : https://nomdupool.domaine.fr/ClientConfigFolder/CustomPresence.xml

Ce chemin correspond à deux dossiers (site interne et externe) qui sont par défaut :

C:\Program Files\Microsoft Lync Server 2013\Web Components\Internal Website\ClientConfigFolder

C:\Program Files\Microsoft Lync Server 2013\Web Components\External Website\ClientConfigFolder

Le fichier se présente ainsi :

   1: <?xml version="1.0"?>
   2: <customStates xmlns="http://schemas.microsoft.com/09/2009/communicator/customStates">
   3: <customState ID="1" availability="online">
   4: <activity LCID="1036">En client&#232;le</activity>
   5: </customState>
   6: <customState ID="2" availability="busy">
   7: <activity LCID="1036">En conversation t&#233;l&#233;phonique</activity>
   8: </customState>
   9: <customState ID="3" availability="do-not-disturb">
  10: <activity LCID="1036">En r&#233;union</activity>
  11: </customState>
  12: </customStates>

Les trois indicateurs de présence possible sont online (Disponible), busy (Occupé(e)) et do-not-disturb (Ne pas déranger).

Le code LCID correspond à la localisation du pays et donc à sa langue. Le code 1336 correspond à la France. Tous les codes sont disponibles sur le site de Microsoft http://msdn.microsoft.com/fr-fr/goglobal/bb964664.aspx.

Les caractères spéciaux doivent être spécifiés selon la norme ISO-8859-1.La liste des différents caractères est disponible via le lien http://www.w3schools.com/tags/ref_entities.asp.

Ajout des statuts à une règle utilisateur

Pour que le client Lync prenne en compte les statuts personnalisés, il faut ajouter le paramètre CustomStateURL à une règle utilisateur. Pour cela utiliser la commande suivante :

Set-CsClientPolicy –Identity <Nom de la règle> –CustomStateURL https://nomdupool.domaine.fr/ClientConfigFolder/CustomPresence.xml

Remarque : Il est possible de faire deux fichiers XML afin d’avoir des statuts personnalisés différents en fonction de la connexion (réseau interne ou réseau externe).

imageimage8

Config Mgr 2012 R2 - Erreur de connexion au portail d’application

Contexte

Dans le produit System Center Configuration Manager 2012 R2 il est possible de mettre à disposition un catalogue d’applications pour les utilisateurs finaux. L'implémentation de ce portail « Self-Service » repose sur un service web et nécessite la mise en place des rôles Config Mgr suivants :

  • Application Catalog web service point
  • Application Catalog website point

L’ajout des deux rôles ne pose aucun problème, cependant il est possible que vous rencontriez le problème ci-dessous lors de l’accès à votre catalogue d’application.

2013-12-06_155211_3

Explication

Bien que l’assistant d’installation des rôles ne vous ait pas remonté de problème, il est possible que les choses ne se soient pas passées comme prévu. Si vous rencontrer le message d’erreur « Cannot connect to the application server », c’est qu’il manque très certainement un composant pour rentre votre portail d’application disponible.

Résolution

Pour identifier la source du problème je vous invite à vous rendre dans le répertoire contenant les logs de Config Mgr 2012 R2. Par défaut les logs se trouvent dans le chemin suivant :
[Program Files]\Microsoft Configuration Manager\Logs

Le fichier qui nous intéresse est nommé SMSAWEBSVCSetup.log. Celui-ci est dédié à l’installation du Web-Service du catalogue d’application.

2013-12-06_155255_2

Lors de l’installation du rôle, une analyse de l’ensemble des éléments prérequis pour la mise en service du Web Services est réalisée. En parcourant le fichier, je découvre que composant Windows Communication Foundation (WCF) n’est pas activé : « WCF is not activated ».

Pour remédier à ce problème, je vous invite à prendre connaissance aux prérequis spécifiques à l’implémentation du rôle « Application Catalog web service point ». http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_Win2k12SiteSystemPrereqs.

Rendez-vous dans votre console Server Manager pour installer la ou les fonctionnalités manquantes pour l’installation du rôle. Il est probable que l’option HTTP Activation ne soit pas activée et qu’elle soit à l’origine de l’erreur. Vous trouverez ci-dessous une capture du lien Technet proposé plus haut et qui détaille les éléments nécessaires pour le bon fonctionnement du portail d’application.

2013-12-10_164313

2013-12-10_165700

Après avoir ajouté les composants manquants, réinstaller le rôle « Application Catalog web service point ».

L’accès à votre portail d’application devrait être à présent fonctionnel.

2013-12-06_163851_3

Desired State Configuration (Partie 2) : LocalConfigurationManager et Mode Push

Introduction

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

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

Il s’agit de la seconde partie qui traite de la configuration du mode Push. Pour rappel, il existe deux modes d’application d’une configuration avec la technologie DSC :

  • Push
  • Pull

Ainsi, nous verrons comment le mode Push fonctionne. Nous nous attarderons ensuite sur la configuration du mode push via une ressource. Enfin, j’expliquerai comment appliquer une configuration en mode Push à distance.

Fonctionnement

Le mode Push est le mode par défaut dans Desired State Configuration. Chaque configuration est poussé par l’utilisateur via ligne de commande ou script directement depuis le serveur concerné ou à distance depuis un autre serveur. L’intérêt de la deuxième option est de centraliser les fichiers “.mof” sur un seul serveur. Pour appliquer la configuration il faut utiliser la commande Start-DscConfiguration (comme vu dans la partie 1).

Ressource LocalConfigurationManager

L’une des nombreuses ressources disponibles lors d’une configuration est nommée : LocalConfigurationManager. Cette dernière permet de définir quand et comment seront appliquées les configurations. Elle est décrite dans le lien ci-dessous :

http://technet.microsoft.com/en-us/library/dn249922.aspx

NB : Au 16/12/2013, le lien comporte des erreurs. Nous allons donc voir ici les différents attributs qui peuvent nous intéresser pour le mode Push.

La ressource LocalConfigurationManager s’utilise comme toutes les autres ressources de DSC. Il va donc être nécessaire de générer un “.mof” contenant cette ressource, puis l’appliquer. Pour récupérer la configuration actuelle  du LocalConfigurationManager  du serveur, il faut utiliser la commande :

001
Get-DscLocalConfigurationManager

 

Le résultat par défaut est le suivant :image Les attributs intéressants pour le mode Push sont :

  • RefreshMode : La valeur doit être à PUSH.
  • ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect sont les valeurs possibles. Apply définit qu’il faut simplement appliquer la configuration. ApplyAndMonitor ajoute une phase de contrôle et loguera les éventuelles dérives de configuration (dans l’observateur d’événements). ApplyAndAutoCorrect réapplique la configuration après chaque nouveau test, s’il y a une dérive.
  • RefreshFrequencyMins : Il s’agit de l’intervalle de temps pour l’actualisation du fichier de configuration. La valeur minimal est 15 minutes.
  • ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
  • RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.

    Voici un exemple de script configurant la ressource LocalConfigurationManager :

    001
    002
    003
    004
    005
    006
    007
    008
    009
    010
    011
    Configuration SetPushMode
    {
        Node WEBSRV01 {
           
            LocalConfigurationManager {
                ConfigurationMode = "ApplyandMonitor" 
                RefreshMode = "Push"
                RefreshFrequencyMins = 30
            }
        }
    }

    On invoque ensuite le bloc Configuration (ligne 1) et on l’applique (ligne 2) afin que la configuration soit prise en compte.

    001
    002
    SetPushMode -OutputPath C:\DSCConfig
    Set-DscLocalConfigurationManager -Path C:\dscconfig\ -ComputerName WEBSRV01 -Credential "WEBSRV01\Administrator" -Verbose

    Ici, les paramètres Credendial et ComputerName sont renseignés permettant d’appliquer la configuration de la ressource à distance.

    Pour que la connexion à distance fonctionne, il est nécessaire de pouvoir se connecter en WMI à distance à “root/Microsoft/Windows/DesiredStateConfiguration”. Pour configurer ce pré-requis, il faut se référer à l’article suivant : http://blog.piservices.fr/post/Powershell-Gestion-a-distance.aspx.

Application d’une configuration à distance

Nous avons vu l’application d’une configuration en mode Push lors de la partie 1. Nous verrons donc ici simplement un complément permettant d’appliquer une configuration à distance. On peut ainsi imaginer un script s’exécutant sur un serveur central possédant tout les fichiers “.mof”. Ce script bouclera sur l’ensemble des serveurs d’une liste et lance les commandes de configuration. Dans cet exemple, on considère qu’un fichier “.mof” a été généré dans “C:\DSCConfig”.

001
Start-DscConfiguration -ComputerName WEBSRV01 -Path C:\dscconfig -Verbose -Wait

Les paramètres utilisés ainsi que les pré requis sont les mêmes que précédemment, seul la cmdlet utilisée change.

SCOM et alertes WMI: Script de redémarrage du service wmi et de ses dépendances

 

Le script suivant récupère les alertes ouvertes pour une machine, qui correspondent a des erreurs de requetage wmi. Si il en trouve au moins une dont le repeatcount est supérieur a une valeur donnée en variable, il redémarre le service wmi et ses dépendances et clos les alertes correspondantes.

   1:  
   2: $scomms="scom2k12sp1srv1"
   3: $targetcomputer="scom2k12sp1dc1"
   4: $repeatcountthreshold="1"
   5: $wmi="WinMgmt"
   6:  
   7: $scomcred=Get-Credential -Credential "scom2k12sp1maq1\administrator"
   8: $arrwmialerts=@(“Operations Manager failed to run a WMI query","Workflow Initialization: Failed to start a workflow that queries WMI for performance data","Workflow Initialization: Failed to start a workflow that queries WMI for WMI events","Operations Manager failed to run a WMI query for WMI events",
   9: "Operations Manager failed to run a performance data WMI query","Workflow Initialization: Failed to start a workflow that queries WMI","Script Based Test Failed to Complete")
  10:  
  11: Import-Module operationsmanager
  12:  
  13: New-SCOMManagementGroupConnection -ComputerName $scomms -Credential $scomcred
  14:  
  15: $arrcomputernewalertnames=Get-SCOMAlert | Where-Object {$_.Resolutionstate -eq "0" -and $_.NetbiosComputerName -eq $targetcomputer -and $_.RepeatCount -gt $repeatcountthreshold -and $_.IsMonitorAlert -eq $false } | Select-Object -Property name -ExpandProperty name
  16: $arrcomputernewalerts=Get-SCOMAlert | Where-Object {$_.Resolutionstate -eq "0" -and $_.NetbiosComputerName -eq $targetcomputer -and $_.RepeatCount -gt $repeatcountthreshold -and $_.IsMonitorAlert -eq $false }
  17:  
  18:  
  19:  
  20: $matchingalerts=0
  21: foreach ($wmialert in $arrwmialerts)
  22: {
  23:   if ($arrcomputernewalertnames -contains $wmialert)
  24:     {
  25:     Write-Host -ForegroundColor Red -BackgroundColor White "L'alerte "$wmialert.ToUpper()" a été répétée plus de $repeatcountthreshold fois sur $targetcomputer"
  26:     Write-Host -ForegroundColor Yellow "Fermeture de l'alerte "$wmialert.ToUpper()" avant redemarrage du service $wmi et de ses dependances"
  27:     $matchingalerts= ($matchingalerts + 1)
  28:     $arrcomputernewalerts | Where-Object {$_.Name -like "$wmialert*"} | foreach {Set-SCOMAlert -ResolutionState 255 -Alert $_ }
  29:     }
  30: }
  31:  
  32:  
  33: ###FUNCTIONS###
  34: Function Restart-Wmi ($targetcomputer)
  35: {
  36: Invoke-Command -ComputerName $targetcomputer -Credential $scomcred -ScriptBlock {
  37: $winmgmt=Get-Service -Name Winmgmt
  38: $winmgmtrundep=$winmgmt.DependentServices | Where-Object {$_.Status -eq "Running"}
  39: Stop-Service -Name Winmgmt -Force -ErrorAction SilentlyContinue
  40: Start-Sleep -Seconds 5
  41: Start-Service -Name Winmgmt -ErrorAction silentlycontinue
  42: Start-Sleep -Seconds 5
  43:  
  44: foreach ($dep in $winmgmtrundep) 
  45:     {
  46:     if (Get-WmiObject win32_service | Where-Object {$_.Name -eq $dep.Name -AND $_.state -ne "running" -AND $_.startmode -eq "Auto"}) 
  47:         {
  48:         write-host -ForegroundColor Green "demarrage de la dependance "$dep.Name.ToUpper()""
  49:         Start-Service -Name $dep.Name -erroraction SilentlyContinue -ErrorVariable ("start_"+$dep.Name+"_error").ToString()
  50:         }
  51:     }
  52:  
  53: }
  54: }
  55:  
  56:  
  57: Function NewEventSource
  58: {
  59:     if(!(Test-Path 'HKLM:\SYSTEM\CurrentControlSet\services\eventlog\Operations Manager\RestartWMIScript'))
  60:     {
  61:     New-EventLog -LogName "Operations Manager" -Source RestartWMIScript
  62:     }
  63: }
  64: ###FUNCTIONS###
  65:  
  66:  
  67:  
  68:  
  69:  
  70:  
  71: if ($matchingalerts -gt 0)
  72: {
  73: write-host -ForegroundColor Yellow "Redemarrage du service WinMgmt et de ses dependances"
  74: Restart-Wmi $targetcomputer
  75: }
  76: else
  77: {
  78: write-host -ForegroundColor Green "Pas d'alertes correspondantes trouvées"
  79: Write-Host -ForegroundColor Green "Pas de redemarrage du service WinMgmt et de ses dependances"
  80: exit
  81: }
  82:  
  83:  
  84:  
  85:  
  86:  
  87: ###VERIFICATION ET LOG D'ERREURS
  88:  
  89:  
  90: Invoke-Command -ComputerName $targetcomputer -Credential $scomcred -ScriptBlock {
  91: param($targetcomputer)
  92: $wmi=Get-Service -Name WinMgmt -ComputerName $targetcomputer
  93: if ($wmi.Status -ne "Running")
  94: {
  95: $function:NewEventSource
  96: Write-EventLog -LogName 'Operations Manager' -Source RestartWMIScript -EntryType Error -EventId 1002 -Message "erreur de demarrage du service winmgmt"
  97: }
  98:  
  99: } -Argumentlist $targetcomputer
 100:  
 101: ###VERIFICATION ET LOG D'ERREURS
 102:  
 103:  
 104:  

KEMP – Déploiement d’une mise à jour sur deux boitiers en mode HA

Contexte

Les boitiers KEMP sont des Appliances de load-balancing. Ces boitiers permettent de répartir la charge des flux entrants.

La mise à jour de ces boitiers s’effectue en plusieurs étapes. L’opération de mise à jour sur deux boitiers (en mode High Availability) prend entre 15 minutes et 30 minutes.

Remarque : La mise à jour de boitiers KEMP implique une légère interruption de service.

Récupérer la mise à jour

Afin de récupérer une mise à jour KEMP il faut contacter l’éditeur via le formulaire suivant :

http://kemptechnologies.com/en/load-balancing-support/contact-support

Sauvegarde de la configuration

Avant de mettre à jour les boitiers, il est important de sauvegarder la configuration actuelle. Il sera ainsi rapide de remettre en place la configuration en cas d’échec de la mise à jour.

Pour se faire, se connecter à la shared IP et se rendre dans la partie System Configuration puis System Administration et enfin Backup / Restore. Cliquer sur Create Backup File. Le navigateur va alors télécharger le fichier de sauvegarde.

1

Sauvegarde des certificats

Il est important de sauvegarder également les certificats en place sur les boitiers.

Depuis l’interface d’administration (sur la Shared IP), aller dans la partie Certificates, Backup / Restore Certs. Insérer un mot de passe puis cliquer sur Create Backup File.

2

Mise à jours des boitiers

La mise à jour se fera ici sur deux boitiers KEMP en HA.

La mise à jour s’effectue dans un premier sur le boitier actif, puis sur le boitier passif (qui sera alors en mode actif).

Depuis l’interface d’administration (sur la Shared IP), aller dans System Configuration, System Administration, Update Software. Cliquer sur Browse…

3

Récupérer le fichier de mise à jour. Cliquer sur Update Machine pour lancer la mise à jour.

45

Un message informe que l’opération peut prendre du temps, cliquer sur OK pour passer à l’étape suivante. Le fichier est alors transféré vers le boitier.

67

Une fois le fichier transféré, une confirmation est demandée, cliquer sur OK.

8

La mise à jour s’installe puis un reboot est demandé. Ce reboot ne concerne que le boitier actif. Il y aura, à ce moment, une petite interruption du service le temps que le boitier passif prenne le relais.

91011

A ce moment de la mise à jour, le boitier est indisponible comme le montre les deux icônes.

12

Une fois l’icône redevenu vert, se connecter sur l’adresse IP du boitier pour vérifier que tout fonctionne correctement.

13

Remarque : Il est préférable de vider la cache du navigateur afin de ne pas voir de fausses informations. Pour cela depuis les options internet, dans l’onglet General, cliquer sur Delete… puis cocher les cases Temporary Internet files, Cookies et History.

1415

Une fois connecté sur le boitier mis à jour, vérifier que la version est bien celle voulue.

16

Refaire les mêmes actions une seconde fois pour mettre à jour le deuxième boitier. Le boitier premier boitier redeviendra ainsi l’actif.

Une fois les deux boitiers mis à jour, depuis l’interface d’administration (sur la Shared IP), vérifier la version.

Lync Server 2013 – Erreur « User is not sip-enabled » dans l’interface du Persistent Chat

Problématique

Dans Lync Server 2013 lorsque le rôle Persistent Chat est activé, il est possible que les utilisateurs rencontrent l’erreur « User is not sip-enabled » lorsqu’ils tentent de se connecter à l’interface d’administration (Ajout / Modification des salles de chat).

Cause

L’erreur se produit généralement avec les navigateurs tiers, en raison d’une mauvaise configuration de l’authentification NTLM.

Résolution

Il est recommandé d’utiliser Internet Explorer pour se connecter à l’interface d’administration. Vérifier que la version d’Internet Explorer est bien à jour.

Pour les aficionados de Firefox, il est possible de modifier sa configuration. Pour cela, dans la barre d’URL taper about:config et cliquer sur Je ferai attention, promis !

image

Rechercher le terme NTLM, puis modifier l’option network.automatic-ntlm-auth.trusted-uris. Insérer l’URL du pool Lync Server https://nomdupool.domaine.fr, valider avec OK.

image image

Redémarrer Firefox. L’accès à l’interface d’administration est alors disponible.

image

ConfigMgr 2012 R2 - Ajout du rôle Reporting Services point - Aucune instance Reporting Services Server disponible

Contexte

System Center Configuration manager offre la possibilité de gérer des rapports via SQL Server. Vous souhaitez ajouter le rôle Reporting Services point sur votre site Config Mgr.
Lors de l’installation du rôle, l’assistant vous demande de renseigner une instance Reporting Services Server sur la page Specify Reporting Services Settings. Vous vous trouvez dans une impasse car aucune instance n’est disponible.

1

Explication

L’implémentation du rôle Reporting Services point s’appuie sur la fonctionnalité SQL Reporting Services.

Il est obligatoire de créer une base de données Report Server Database. Sans cette configuration préalable, le service de rapport n’est pas fonctionnel. Dans ses conditions, impossible d'installer le Reporting Services point dans notre site Config Mgr. La résolution du problème consiste donc à configurer le service SQL Reporting Services.

Résolution

1. Dans un premier temps, vérifier que votre instance SQL comporte la fonctionnalité Reporting Services – Native.

2
   

2. Lancer l’utilitaire Reporting Services Configuration Manager

3. Tous d’abord rendez-vous dans l’onglet Web Services URL.

a. Dans cet onglet, il est possible de modifier différents paramètres. Tel que le nom du répertoire virtuel et les paramètres réseaux.

b. Valider la configuration en appuyant sur Apply. Le fait d’appliquer la configuration va permettre de créer la base de données du serveur de rapports. Cliquez sur Apply même si vous n’avez pas modifié les paramètres.

3

c. Quelques instants plus tard, la zone Results vous informe que le répertoire virtuel a bien été créé. Vous devriez à présent voir apparaitre le lien dans le champ Report Server Web Service URLs.

4

4. Rendez-vous ensuite dans l’onglet « Report Manager URL »

a. Valider la configuration en appuyant sur Apply.

5

5. Quelques instants plus tard, la zone Results vous informe que le répertoire virtuel a bien été créé.

6

6. Le service SQL Reporting Services est maintenant configuré et fonctionnel. Vous pouvez relancer l’assistant Config Mgr pour ajouter le rôle Reporting Services point à votre site SCCM.

7

Quelques outils pour votre infrastructure

Je vous propose ici quelques outils (venant de Microsoft pour la plupart) qui vous permettrons de planifier le déploiement d’un serveur, d’obtenir des statistiques, de gérer plus facilement ou encore de diagnostiquer votre infrastructure.

Active Directory

Générateur de topologie Active Directory :
http://gallery.technet.microsoft.com/Active-Directory-Topology-3a334bba

Active Directory Replication Status Tool :
http://www.microsoft.com/en-us/download/details.aspx?id=30005

Planning de déploiement Active Directory pour MS Project:
http://office.microsoft.com/en-us/templates/microsoft-active-directory-deployment-TC001130774.aspx

Exchange

Calculer les prérequis matériels pour le déploiement de votre infra Exchange 2013
http://gallery.technet.microsoft.com/Exchange-2013-Server-Role-f8a61780

Générer des statistiques sur votre Exchange – Support Ex2010 & 2013
http://gallery.technet.microsoft.com/office/Exchange-Server-Mailbox-7dd53529

Simuler des accès à la base Exchange avec l’outil JetStress
http://www.microsoft.com/en-us/download/details.aspx?id=36849

Visualiser simplement et rapidement les logs Exchange
http://blogs.technet.com/b/exchange/archive/2013/06/17/log-parser-studio-2-2-is-now-available.aspx

Gérer les rôles RBAC (à partir d’Exchange 2010 SP2)(non Microsoft)
http://rbac.codeplex.com/

Générer un rapport sur l’infrastructure Exchange entière (non Microsoft)
http://www.stevieg.org/2011/06/exchange-environment-report/

Tester la connectivité de votre serveur Exchange avec Internet
https://www.testexchangeconnectivity.com/

Lync

Calculer les prérequis matériel pour le déploiement de votre infra Lync 2013
http://www.microsoft.com/en-us/download/details.aspx?id=36828

Tester la connectivité de votre serveur Lync avec Internet
https://www.testexchangeconnectivity.com/

 

Architecture des produits

Microsoft met régulièrement à disposition des posters présentant l’architecture de ses produits phares. Voici les liens pour les télécharger :

Exchange 2013 : http://aka.ms/Ex2013ArchitecturePoster

Lync 2013 : http://www.microsoft.com/en-us/download/details.aspx?id=39968

SharePoint 2013 : http://go.microsoft.com/fwlink/p/?LinkId=271932

Active Directory 2008 : http://www.microsoft.com/en-us/download/details.aspx?id=17881

Si vous avez Windows 8, je vous conseille l’application PosterPedia de Microsoft (http://apps.microsoft.com/windows/fr-fr/app/posterpedia/f988071c-66dc-4281-8028-637ac0f09061). Vous aurez accès à tous les posters très simplement.

 

Bonus

Si vous êtes un adepte des schémas sous Visio, je ne peux que vous conseillez de télécharger le pack de forme suivant : http://www.microsoft.com/en-us/download/details.aspx?id=35772. Il regroupe les dernières formes pour Visio pour les serveurs Exchange 2013, Lync 2013, SharePoint 2013 et Office 365.

A vos schémas !

Desired State Configuration (Partie 1) : Introduction et syntaxe

Introduction

Powershell 4.0 (introduit avec Windows 2012 R2) apporte son lot de nouveautés. La plus importante est : Desired State Configuration.

En entreprise, il existe deux problématiques récurrentes au sein d’un système d’informations :

  • L’augmentation du nombre de serveurs
  • Le changement

Desired State Configuration apporte une solution à ces questions en proposant une solution pour l’automatisation des déploiements et la maintenance des serveurs (contrôle et retour en conformité).

Avec cette fonctionnalité, il sera possible de déployer rapidement et à grande échelle des améliorations à une infrastructure, tout en s’assurant que les systèmes ne varient pas au cours du temps.

Par exemple, on peut vouloir s’assurer qu’un groupe de serveurs web possède :

  • le rôle adéquat correctement configuré,
  • les services nécessaires démarrés
  • les sources valides d’un site web copiées dans le bon répertoire
  • la bonne adresse IP pour chaque serveur.

DSC permet de configurer un serveur via un script au travers d’une syntaxe simple (similaire aux fonctions Powershell). Les possibilités de configuration sont infinies (rôles, groupes et utilisateurs locaux, registre…). Cette configuration peut se faire en local ou à distance. De plus, au delà de la première application de la configuration du serveur, il existe des mécanismes de contrôles. Avec Desired State Configuration, Windows peut automatiquement vérifier si sa configuration est correcte et la remettre à niveau s’il y a eu un changement anormal. Ainsi, les dérives de configuration sont évitées !

    Pour appliquer une configuration, il existe deux modes :

  • Push : La configuration est envoyé au serveur
  • Pull : La configuration est demandé par le serveur client vers un serveur centrale qui gère toutes les configurations possibles.

Grâce au scripting il va être possible d’appliquer des configuration à des groupes de serveurs.

DSC est basé sur les fichiers “.mof”. Il est possible de les générer de la façon que l’on souhaite (éditeur de texte par exemple). Powershell 4.0 permet de simplifier la génération de ses fichiers notamment grâce à l’auto complétion mais aussi avec syntaxe accessible. Via le module PSDesiredStateConfiguration, on peut créer ses fichiers et les utiliser pour appliquer une configuration.

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

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

Les ressources

Les éléments que l’on va pouvoir configurer sont appelés ressources.

Voici quelques exemples de ressources disponibles nativement : l’exécution de services, de clés de registre, de scripts ou de variables d’environnement. Les groupes et utilisateurs locaux ainsi que la copie de fichiers sur un serveur est aussi gérable. Les possibilités sont infinies.

Il est aussi possible de créer ses propres ressources, en définissant la façon de réaliser la configuration sur le serveur et de tester la conformité. Ainsi on peut imaginer une ressource qui s’occupera de la gestion du fichier “hosts”, un autre peut gérer la configuration IP ou même la présence et l’activation de règle firewall.

La liste des ressources disponibles nativement est listé dans le lien suivant : http://technet.microsoft.com/en-us/library/dn249921.aspx

La syntaxe

La syntaxe Powershell implémentée se base sur le mot clé Configuration. Voici un exemple :

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
Configuration TestDSC 
{ 

  Node WEBSRV01 #Nom du serveur
  { 
    WindowsFeature IIS 
    { 
      Ensure = “Present” #Vérifie que le rôle est présent
      Name = “Web-Server” #Nom du rôle ou de la fonctionnalité à vérifier
    } 

    File DirectoryCopy
    {
        Ensure = "Present" #Vérifie que les fichiers/dossiers sont présents
        Type = "Directory" #Type d'objet à vérifier
        Recurse = $true #Inclus les fichiers/dossiers enfants
        SourcePath = "\\FILESRV01\MyWebSite" #Chemin des sources
        DestinationPath = "C:\inetpub\wwwroot\MyWebsite" #Destination où doivent se trouver les données
    }
   
    Group ViewerGroup
    {
        Ensure = "Present" #Vérifie qu'un groupe est présent
        GroupName = "Viewer" #Nom du groupe
    }
  } 
}

La déclaration se fait donc via des blocs entre accolades. Dans un bloc de type Configuration, on a un ou plusieurs blocs Node. Pour chaque bloc Node, un fichier MOF sera généré. A côté de ce mot clé, on inscrit le nom du serveur qui possédera cette configuration. A l’intérieur de chacun de ses blocs se trouvent les ressources que l’on souhaitent configurer. Dans l’exemple précédent, on retrouve dans l’ordre les 3 ressources suivantes :

  • WindowsFeature : S’assure que le rôle IIS est installée.
  • File : Vérifie que les fichiers sont bien présents sur le répertoire de destination.
  • Group : Constate que le groupe local Viewer existe.

Dans le cas où l’une des ressources retournerait un résultat incorrect alors l’opération serait réalisée afin de mettre l’ordinateur en conformité. Par exemple, pour les sources du site web (Ressource WebsiteDirectory), le fichier de configuration possède le chemin source et la destination.

Pour générer le fichier MOF, il faut appeler notre configuration comme une fonction Powershell :

001
TestDSC -OutputPath c:\DSCConfig

Le paramètre OutputPath (facultatif) définie le dossier où vont être stockés les fichiers de configuration. Le fichier créé portera le nom de la machine portant cette configuration (ici WEBSRV01).

A l’instar des fonctions, on peut utiliser des paramètres. Voici, un exemple similaire au précédent où l’on spécifie la source et la destination des fichiers du site web ainsi qu’une liste de nom d’ordinateur auxquels appliquer cette configuration.

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
Configuration TestDSC 
{ 
 
  param(
    [Parameter(Mandatory=$true)]
    [String[]]$Computers,
    [Parameter(Mandatory=$true)]
    [String]$SourceWeb,
    [Parameter(Mandatory=$true)]
    [String]$DestinationWeb 
  )

  Node $Computers 
  { 
    WindowsFeature IIS 
    { 
      Ensure = “Present” 
      Name = “IIS-Server” 
    } 

    File DirectoryCopy
    {
        Ensure = "Present"
        Type = "Directory"
        Recurse = $true 
        SourcePath = $SourceWeb
        DestinationPath = $DestinationWeb 
    }

  } 
}

Il y aura autant de fichiers MOF générés que de noms dans le paramètre Computers. Voici la commande pour créer les fichiers MOF :

001
002
003
TestDSC -Computers @("WEBSRV01","WEBSRV02","WEBSRV03") `
-SourceWeb "\\FILESRV01\MyWebSite" -DestinationWeb "C:\inetpub\wwwroot\MyWebsite"`
-OutputPath c:\DSCConfig

Application d’une configuration

Ici, nous allons aborder brièvement l’application d’une configuration en local via le mode Push. Le détail de ce mode est expliqué dans la partie 2 de l’article sur Desired State Configuration. On utilise la commande Start-DscConfiguration. Voici l’explication des paramètres utilisées dans la commande ci-dessous :

  • Wait : Ne rend pas la main à l’utilisateur tant que la commande est en cours d’exécution (Par défaut l’exécution de DSC se fait en arrière plan).
  • Verbose : Affiche les opérations effectuées.
  • Path : Le dossier où se toruve le fichier MOF (DSC choisi le fichier portant le nom de l’ordinateur).
001
Start-DscConfiguration -Wait -Verbose -Path C:\DSCConfig

Il ne peut y avoir qu’une configuration active par machine. Si une seconde configuration est appliquée, il n’y aura plus de contrôle de conformité sur les ressources non présentes dans la nouvelle configuration.