Notre blog déménage

Bonjour à tous

Tout d’abord désolé de ce très long silence. Je sais, je sais, je n’ai pas d’excuses mais j’avoue que ces derniers mois, j’ai eu la tête sous l’eau et donc beaucoup de mal à trouver du temps pour m’occuper de mon blog.

Mais bon, une bonne nouvelle en chasse une mauvaise !  Je suis donc heureux de vous annoncer la mise en ligne d’un nouveau blog qui devrait être dans la continuité de celui ci. Je compte sur vous pour me remonter vos commentaires (bons ou mauvais!), c’est la seule manière de s’améliorer.

Je vous donne rendez vous dès à présent sur : Network Architects IT Blog

Merci à vous

Hamid AICHE

 

Gartner – Magic Quadrant for Secure Email Gateways 2015

Le 29 juin 2015.  Gartner vient de publier son rapport Magic Quadrant for Secure Email Gateway pour cette année 2015.  Microsoft glisse doucement mais surement dans le carré des leaders, rejoignant ainsi Proofpoint et Cisco ! Barracuda et Sophos, qui figuraient précédemment dans le carré des challengers aux cotés de Symantec, redescendent au rang de niche players.

Lire l’article complet ici.

Exchange 2010 – Déplacement de boites aux lettres 1/2

Le déplacement de boites aux lettres  est à la base de toute migration Exchange. L’opération peut bien entendu être effectuée depuis la console EMC mais nous allons voir ici, que la méthode PowerShell offre infiniment plus de possibilités. Nous allons tout d’abord donner quelques exemples simples de la commande New-MoveRequest pour nous habituer à sa syntaxe et finir avec quelques exemples un peu plus complexes.

Example 1 : 

New-MoveRequest - Identity "Bill.Pullman"  -TargetDatabase "DB01"

La commande permet simplement de déplacer la boite aux letters de Bill Pullman vers la base de données DB01. Le paramètre Identity doit permettre d’identifier la boite au lettres sans ambiguité. La valeur transmise peut être l’Alias, le login, l’adresse SMTP, …

TargetDatabase fait bien sur référence à la base de données cible vers laquelle la boite aux lettres sera déplacée. Example 2 :

Il peut arriver parfois qu’une boite aux lettres contienne des éléments corrompus. Dans ce cas, le déplacement de la boite concernée échoue dés qu’un élément corrompu est détecté. Cela peut être assez déplaisant lorsque cela arrive une fois 94% du déplacement effectué. Pour éviter cela, il est possible de renseigner le paramètre BadItemLimit  qui définit le nombre acceptable d’éléments corrompus. Ces derniers seront tout simplement ignorés par le processu de déplacement. Si vous estimez que ce nombre doit être être supérieur à 50, dans ce cas vous devrez également ajouter le paramètre AcceptLargeDataLoss  à votre commande.

New-MoveRequest - Identity "Bill.Pullman"  -TargetDatabase "DB01" -BadItemLimit 5

ou encore

New-MoveRequest - Identity "Bill.Pullman"  -TargetDatabase "DB01" -BadItemLimit 100 -AcceptLargeDataLoss

Example 3 :

Généralement, et particulièrement lors d’une migration, le déplacement des boites aux lettres doit être effectué par lot et non pas une boites après l’autre.  Dans ce cas, comment transmettre à la commande New-MoveRequest la liste des boites aux lettres à déplacer ? Eh bien, c’est la que la magie de PowerShell opère :

Pour déplacer toutes les boites aux lettres de la base « Old-Database » vers la base « DB01 », la commande est la suivante :

Get-Mailbox -Database "Old-Database" | New-MoveRequest -TargetDatabase "DB01" -BadItemLimit 100 -AcceptLargeDataLoss

La première partie de la commande (à gauche du |) récupère la liste des boites au lettres de la base de données « Old-Database » et la transmet ensuite à la commande New-MoveRequest. Si nous voulions déplacer tous les utilisateurs dont le nom commence par la lettre « B » par exemple, la commande serait alors  :

Get-Mailbox -Identity "B*" | New-MoveRequest -TargetDatabase "DB01" -BadItemLimit 100 -AcceptLargeDataLoss

Déplacement des boites au lettres des utilisateurs figurant dans l’unité d’organisation « Marketing ».

Get-Mailbox -OrganizationalUnit "Marketing" | New-MoveRequest -TargetDatabase "DB01" -BadItemLimit 100 -AcceptLargeDataLoss

Toute l’arborescence de l’unité d’organisation « Marketing » sera traitée. Autrement dit, si l’OU marketing contient deux autres OU : Manager et Assistants, les boites au lettres contenues dans ces dernières seront également déplacées.

Il est également possible de déplacer les boites aux lettres dont la liste est contenue dans un fichier CSV. Celui  ci doit impérativement contenir à la première ligne le nom de la colonne et sur chaque ligne suivante une valeur à transmettre à la commande.

Exemple de fichier CSV (contenant 4 lignes):

Import-CSV ".\users.txt" | foreach {New-MoveRequest -Identity $_.Nom -TargetDatabase DB01 -BadItemLimit 10} 

Notez bien que le nom de la variable $_.Nom correspond au nom de la colonne utilisée dans le fichier CSV.

Une petite remarque au passage : lorsque vous effectuez plusieurs déplacement par lot, nous verrons dans la deuxième partie de cet article qu’il peut être bien pratique de pouvoir différencier entre les différentes vagues de déplacement effectuées. Pour cela, pensez à glisser le paramètre BatchName dans chacune de vos commandes. Par exemple :

Get-Mailbox -Database "Old-Database" | New-MoveRequest -TargetDatabase "DB01" -BatchName "Moving Mailbox from Old-Database" -BadItemLimit 100 -AcceptLargeDataLoss

Example 4 : Pour finir, nous allons voir l’usage d’un paramètre assez peu connu et pourtant bien pratique : SuspendWhenReadyToComplete.

Lors d’un déplacement de boite aux lettre avec la commande New-MoveRequest, le contenu de la boite est copiée message par message depuis sa base d’origine vers la base de destination. Ce n’est qu’une fois la copie effectuée sans erreurs que les attributs active directory de la boite aux lettres sont modifiées pour refléter le changement de base de données.

Que diriez vous s’il était possible de suspendre le déplacement une fois la copie de la boite aux lettres effectuée. Mieux encore, que diriez vous si cette copie pouvait être maintenue synchronisée avec l’originale pendant 1 mois entier. Vous auriez donc la possibilité de finaliser le déplacement à tout moment et cela ne prendrait que quelques secondes puisque la copie a déjà été effectuée. Eh bien, c’est exactement ce que l’attribut SuspendWhenReadyToComplete permet de réaliser.

Get-Mailbox -Database "Old-Database" | New-MoveRequest -TargetDatabase "DB01" -BatchName "Moving Mailbox from Old-Database" -BadItemLimit 100 -AcceptLargeDataLoss -SuspendWhenReadyToComplete

Vous pourrez alors à tout moment finaliser le déplacement avec la commande Resume-MoveRequest.

Get-MoveRequest | ?{$_.Status -Eq "AutoSuspended"} | Resume-MoveRequest

Dans la deuxième partie de cet article, nous verrons comme suivre en direct le déplacement de boites aux lettres initié par New-MoveRequest et générer des rapports détaillés sur les déplacements réalisés.

A très bientôt.

PS :

Par défaut, le service de réplication de boites aux lettres, n’autorise le déplacement que de deux (02) boites aux lettres à la fois. Pour augmenter ce nombre, et autoriser le déplacement de 20 boites simultanément par exemple, procédez comme suit :

• Sur vos serveurs CAS, ouvrez le fichier C:\Program Files\Microsoft\Exchange Server\V14\Bin\MSExchangeMailboxReplication.exe.config avec le Bloc Note (exécuté en tant qu’administrateur)
• Modifier les lignes suivantes :
  • MaxActiveMovesPerSourceMDB = “20” (valeur par défaut : 5)
  • MaxActiveMovesPerTargetMDB = “20″ (valeur par défaut : 2)
  • MaxActiveMovesPerTargetServer = “20” (valeur par défaut : 5)

Enregistrez les modifications puis redémarrez le service de réplication de boites aux lettres :

restart-service MSExchangeMailboxReplication -Force

That’s it

Exchange 2010 – Vérifier l’état du DAG

Un peu de théorie avant d’aborder la pratique :

Le DAG (Data Availability Group ou encore Groupe de Disponibilité de Base de Données)  est le composant de base de l’architecture de haute disponibilité et de résilience de site intégrée à Exchange 2010. Un DAG est un groupe pouvant être formé d’un maximum de 16 serveurs de boîtes aux lettres qui hébergent un ensemble de bases de données et assurent une récupération automatique au niveau de la base de données à la suite de défaillances affectant des bases de données individuelles. N’importe quel serveur d’un groupe de disponibilité de base de données peut héberger une copie de base de données de boîtes aux lettres provenant d’un serveur quelconque du groupe de disponibilité de base de données. Lorsqu’un serveur est ajouté à un groupe de disponibilité de base de données, il fonctionne avec les autres serveurs du groupe pour assurer la récupération automatique à la suite de défaillances affectant des bases de données de boîtes aux lettres, par exemple la défaillance d’un disque ou d’un serveur.

De manière générale, un DAG est un élément particulièrement stable de l’architecture Exchange et à moins d’une saturation du disque contenant les logs (un grand classique) une grosse panne réseau ou d’un méchant crash serveur, il est assez rare de voir un DAG  se prendre les pieds dans le tapis.

Une des taches importantes de tout administrateur Exchange est donc de veiller à ce que le DAG se maintienne en bonne santé. Quelques contrôles réguliers suffisent généralement à éviter les gros problèmes :

1. Surveiller l’espace disque disponible (notamment sur les disques contenant les log et les bases)
2. S’assurer que tous les services sous jacents sont opérationnels sur l’ensemble des serveurs du DAG
3. S’assurer que toutes les copies de bases de données sont saines

Pour le premier point, vous avez l’embarras du choix :

• un coup d’oeil régulier sur les serveurs
• un script planifié
• application type SCOM (Microsoft System Center Operation Manager) ou tout autre application de monitoring (y en a des tas de gratuites)

Pour le deuxième et le troisième point:

• La méthode manuelle en Powershell :

Vérifier que tous les services du DAG sont opérationnels (attention, les parenthèses sont importantes)

(Get-DatabaseAvailabilityGroup -Identity DAG).servers | Test-ReplicationHealth

 

Si une erreur est signalée (c’est assez rare, je vous rassure), c’est qu’un service est probablement arrêté ou qu’il est temps d’appeler le plombier 🙂

Vérifier que toutes les copies de bases de données sont saines :

(Get-DatabaseAvailabilityGroup -Identity DAG).servers | foreach {Get-MailboxDatabaseCopyStatus -Server $_.Name} |  Select Name, Status, ContentIndexState

Quand tout va bien, la colonne Status affiche Healthy (pour les copies passives) ou Mounted (pour la copie active). Il arrive assez souvent de voir un ContentIndexState afficher Failed. Rien de bien méchant : en général, la suspension puis la remise en route de la réplication suffit à faire disparaître l’erreur.

• L’utilisation d’un script plus élaboré  :

Le plus répandu est probablement l’excellent Get-DAGHealth de Paul Cunningham que vous pourrez télécharger sur son site.

L’exécution du script produit un fichier HTML donnant un bilan très complet de l’état de santé de votre DAG.

Quelque soit la méthode utilisée, l’important est de ne pas négliger la surveillance de votre environnement. L’adage « prévenir  vaut mieux que guérir » prend ici toute sa dimension :-).

Bonne chance à tous.

Free Microsoft ebooks

Probablement la plus importante (environ 150 titres) collection d’ouvrages Microsoft. Tout cela est bien entendu gratuit et surtout parfaitement légal 🙂

Ça se passe par ici ->

 

PowerShell – Récupérer la liste des serveurs Windows depuis Active Directory

Pour rester dans l’esprit du billet précédent, voici un petit script pour récupérer la liste des serveurs Windows directement depuis Active Directory. Simple et efficace.

Import-Module ActiveDirectory
$Computers = Get-ADComputer -Filter {OperatingSystem -Like "Windows *Server*"} | select Name
$Computers | out-file .\servers.txt
(Get-Content .\servers.txt| Select-Object -Skip 3) | Set-Content .\servers.txt

PowerShell – Comment trouver tous les serveurs utilisant un compte de service donné

Je pense que tout le monde s’est posé la question un jour ou l’autre : A quoi correspond ce fichu compte de service BizarreServiceAccount qui figure parmi les Admins du domaine ?

Personne n’en revendique la paternité mais personne n’ose le désactiver de peur de bloquer une application super critique installée en 1969 par on ne sait plus qui mais dont on ne peut plus se passer !

Résultat des courses, on se retrouve souvent avec une panoplie de comptes de service avec un niveau de privilège élevé et dont on ne sait finalement rien.

Le script qui suit, fait un travail finalement très simpliste mais qu’il serait fastidieux de reproduire de manière manuelle : ce petit bout de code powershell va accéder à chaque serveur présent dans un fichier servers.txt (qu’on aura préalablement renseigné avec la liste des serveurs de l’entreprise), et rechercher les services utilisant le compte de service LogonAccount (fourni en paramètre). Le résultat de la recherche est sauvegardé dans le fichier CSV services.csv.

param(
    [parameter(Mandatory=$true)][string]$LogonAccount
    )

$output = @()
$i = 0
$outFile = ".\services.csv"
$Computers = Get-Content -Path .\Servers.txt

write-Host "Initializing..."

$Count = $Computers.count

Write-Host Found $count Computers.

foreach ($Computer in $Computers ) {

  $i++
  $Computer = $Computer.trim()  
  Write-Progress -Activity "Getting service information" -Status "Processing  $Computer" -PercentComplete (100 * ($i/$count))
  Write-Host "Processing "  -f white -NoNewline
  Write-Host $Computer -f Yellow -NoNewline

  if (Test-Connection -ComputerName $Computer -BufferSize 16 -Count 1 -Quiet) {

    Write-Host " (OK)" -f Green -NoNewline
    $WMIQuery = Get-WmiObject -Class Win32_Service -ComputerName $Computer -ErrorAction SilentlyContinue
    $Services = $WMIQuery | ? { $_.StartName -match $LogonAccount } | select DisplayName, StartName, State 

    if ($Services) {
      foreach ($Service in $Services) {
	    $obj = New-Object PSObject
	    $obj | Add-Member NoteProperty "Server"  -Value $Computer
	    $obj | Add-Member NoteProperty "Service" -Value $Service.DisplayName
	    $obj | Add-Member NoteProperty "State"   -Value $Service.State
	    $obj | Add-Member NoteProperty "Account" -Value $Service.StartName
            $output += $Obj
      }
      Write-Host " [MATCH FOUND]" -f Yellow

    } else { Write-Host "." }

  } else {
    Write-Host " (Unreachable)" -f Red
  }

}

Write-Progress -Activity "Getting services information" -Status "Completed" -Completed
Write-Host Completed.
$output | Export-Csv -Path $outFile -NoTypeInformation -Delimiter ";"

Exchange 2010 multi-roles et Haute Disponibilité (Part 1/2)

Question : on met à votre disposition 2 serveurs pour déployer une plate-forme Exchange 2010 hautement disponible. Quelle solution proposez vous ?

La première réponse qui vient à l’esprit est :

1. installer Exchange 2010 en multi-roles (Mailbox, Hub et Cas) sur les deux serveurs
2. configurer un DAG pour la haute disponibilité des bases de données
3. créer un CAS Array
4. mettre en place NLB pour la haute disponibilité des CAS et pointer le Cas Array sur l’adresse ip virtuelle NLB.

Pas mal, mais il y a un hic de taille : on ne peut malheureusement pas installer la fonctionnalité Windows Network Load Balancing (NLB) sur un serveur qui est deja membre d’un DAG. Il s’agit la d’une limitation Windows qui fait qu’il n’est tout simplement pas possible de mixer du Failover Clustering (utilisé par le DAG) avec du Clustering NLB sur un même serveur.

C’est d’ailleurs pour cela que les premières architectures HA Exchange 2010 s’appuyaient le plus souvent sur des modèles à 4 serveurs (2 serveurs CAS/HUB en NLB et 2 serveurs MBX en DAG).

Ce qu’on retient donc pour l’instant :

• la mutualisation des rôles n’a pas d’intéret particulier (sauf dans un environnement mono serveur bien sur)
• pour une haute disponibilité de tous les rôles, 4 serveurs au minimum sont requis.

Lors du TechEd 2010, Microsoft change quelque peu son fusil d’épaule et cesse de recommander Windows NLB comme mécanisme de haute dispo pour les CAS. Voir slide ci dessous. La présentation complète est disponible ici en téléchargement (PPTX, 7,5MB).

 

 

La recommandation est claire et sans équivoque : Utilisez donc un Load balancer (répartiteur de charge). La liste des équipements validés par Microsoft peut être consultée sur le site de l’éditeur.

A partir de la, les architectures Exchange 2010 HA de référence changent et les modèles à base de serveurs multi-roles font leur apparition (NLB n’etant plus la pour jouer les troubles fêtes). Microsoft recommande même clairement d’opter pour un modèle à base de serveurs multi-roles avec pour arguments : une meilleur utilisation des ressources et une simplification du déploiement. Voir ref :

• https://technet.microsoft.com/fr-fr/library/dd298121(v=exchg.141).aspx (en francais)
• http://blogs.technet.com/b/exchange/archive/2011/04/08/robert-s-rules-of-exchange-multi-role-servers.aspx

A l’époque cependant, Load Balancer est encore souvent synonyme de F5 Big-IP et autres Citrix Netscaler pour ne citer que ceux la, des produits réputés pour être budgetivores et donc réservés aux grands comptes. Fort heureusement, c’était sans compter sur l’arrivée de constructeurs comme KEMP Technologies ou encore Barracuda Networks (il y en a d’autres bien sur) qui ont mis sur le marché des équipements tout à fait convenables et à des prix abordables, mettant ainsi le load balancer à la portée de tous.

Malgré cela, nous continuons à recevoir encore et encore des demandes pour le déploiement de plate-forme Exchange 2010 haute dispo avec dans les cartons deux serveurs et basta. Force est de constater que malgré la baisse des prix, l’usage de load balancers n’est toujours pas entré dans les moeurs.

Beaucoup d’articles sur internet traitent du problème de haute dispo dans les environnements Exchange 2010 à base de serveurs multi-role. Cela va de la mise en oeuvre de DNS Round Robin à la mise en place de scripts Powershell permettant de changer à la volée l’adresse du CAS Array en cas d’indisponibilité d’un des serveurs.

Il existe cependant une manière originale et très simple de régler controurner le problème. Et c’est paradoxalement, la moins documentée.

Nous donnerons le détails de cette mise en oeuvre dans la seconde partie de cet article. Désolé, vous allez devoir patienter quelques jours encore 🙂 D’ici la, tous vos commentaires sont les bienvenus.

En attendant, je vous recommande quelques lectures intéressantes sur le sujet :

• http://blogs.technet.com/b/exchange/archive/2011/04/08/robert-s-rules-of-exchange-multi-role-servers.aspx
• https://www.microsoftpressstore.com/articles/article.aspx?p=2225066&seqNum=3
• http://www.sysadminsblog.com/microsoft/full-failover-with-two-exchange-2010-servers/

A la semaine prochaine.

Windows Server 2003 – Fin de support en juilllet !

 

C’est officiel, Microsoft mettra fin au support de Windows Server 2003 le 14 Juillet 2015.

En d’autres termes, plus aucun correctif de sécurité ne sera publié après le 14 juillet. Bonjour les malwares et autres charmantes bêtes à la recherche de la moindre faille de sécurité. Et je ne vous parle pas de problèmes de compatibilité (hardware et software) que vous ne manquerez pas de rencontrer.

Si le projet de migration de vos serveurs 2003 n’est pas dans votre “Todo list” pour 2015, il est encore temps de revoir vos priorités !

Le mieux est encore de commencer ici : Fin du support de Windows Server 2003

Forefront Protection 2010 for Exchange : il est encore temps !

Bien que le produit ait été retiré du catalogue Microsoft en septembre 2012, je peux vous dire qu’il est encore largement présent dans les entreprises.

Juste une date à retenir : le 31 décembre 2015 (oui oui je sais, c’est aussi le nouvel an), les mises à jour de signatures arriveront à expiration, définitivement. Terminé, fini, kapout, il ne vous restera plus que vos yeux pour pleurer et espérer que rien de facheux n’arrivera d’ici à ce que vous ayez trouver une solution de secours.

Alors, si vous avez la chance de travailler dans une des nombreuses entreprises ou la signature du moindre bon de commande prend des mois, je vous conseille vivement de prendre un peu d’avance et de commencer l’écriture de votre cahier des charges, mettre la pression sur la direction en exposant les dangers (malheureusement réels !) auxquels l’entreprise risque de s’exposer en cas d’expiration de l’antivirus, devenez copain avec le directeur financier si nécessaire mais de grâce n’attendez pas le dernier moment pour aller faire votre marché.

Bonne chance à tous 🙂

PS : pour rappel