PI Services

Imaginons que vous deviez effectuer un net use dans un script sur plusieurs machines mais que les disks drive disponible ne soit pas les mêmes. Pour cela, nous allons consulter le registre.

Dans le registre, chaque disk drive monté apparait dans HKCU\Network

Exemple :

Un net use

Sous le registre

Avec la cmdlet Get-Random, nous pouvons emprunter une lettre pour un disk drive aléatoire et voir si la clé dans le registre au niveau de HKCU\network est retrouvé par notre valeur obtenu du Get-Random . Si cela n’est pas le cas, cela veut dire que la lettre est disponible pour notre disk drive.

Récupérer une lettre disponible dans une variable

Pour notre cmdlet get-random, nous définissons une collection de valeur allant de o à z.

Pour chaque valeur obtenue, nous allons vérifier si la clé correpondante dans le registre sous HKCU\Network existe. La variable récupérera donc une valeur qu’il comparera au registre.

do {$MapDest=get-random -input "o","p","q","r","s","t","u","v","w","x","y","z"; get-childitem "registry::HKEY_CURRENT_USER\Network\$MapDest"; $check=$?} while ($check -eq "true")

Notre variable a maintenant une lettre de lecteur disponible pour un mappage de lecteur réseau. Il ne reste plus qu’à ajouter à notre variable $MapDest le caractere “:”

$MapDest=("$MapDest :").replace(" ","")

La variable peut maintenant être utilisé pour un mappage : net use $MapDest \\path

La commande get-credential obtient un objet credential (informations d'identification) basé sur le nom et mot de passe d'un utilisateur.

Cependant, cette commande est incompatible avec les fournisseurs installés avec Windows Powershell.

Exemple d’une copie de fichier sans crédential

Maintenant, essayons en spécifiant un utilisateur.

On peut donc voir que le fournisseur n’est pas compatible en définissant un crédential.

Maintenant, nous allons voir comment permettre une authentification via le module impersonation disponible à cette adresse : http://poshcode.org/get/1867

Cette astuce devra être exécuté avec Powershell en mode STA : Single-Threaded Apartments car le module que nous allons importer n’est compatible que dans ce mode.

Exécuter :

(En mode STA, la fenêtre Powershell est noir par défaut)

Maintenant on récupère notre variable d’authentification comme auparavant.

Si on exécute une copie de fichier avec la variable $cred, on peut voir que cela ne fonctionne toujours pas.

Maintenant, on va importer le module « impersonation » qui va mettre à notre disposition trois nouvelles commandlets.

A l’aide de Push-ImpersonationContext, on va maintenant récupérer notre variable $cred. Et à partir de là, on peut réessayer une copie de fichier qui auparavant ne fonctionnait pas.

Cela fonctionne désormais.

Pour effacer de la mémoire l’authentification, nous avons la variable Pop-impersonationContext disponible.

Exemple :

Nous supprimons le fichier copié là où celui-ci a fonctionné auparavant et nous utilisons la cmdlet Pop-impersonationContext. Nous réessayons donc une nouvelle fois notre copie de fichier :

Cela a bien supprimé l’authentification gardé en mémoire.

Autre exemple d’authentification pour la création d’un item  (même principe):

Independemment de la portabilité des variable dans un script, un problème se pose lorsque vous souhaitez, dans un script, accéder des variable locales depuis des commandes executées sur une machine distante.

Exemple:

$vmmserver="monserveurvmm.home.com"
$VmToStop="c:\BackupAdmin\VMToStop.txt"

if (!(test-path $VmToStop))
{
write-host "le fichier des VM $VmToStop a eteindre introuvable. le script va s'arreter"
Exit
}
else
{
$VmToStop= Get-Content $VmToStop
foreach ($vm in $VmToStop)
{

        Invoke-Command -ComputerName $vmmserver -ScriptBlock {
        param($vm,$vmmserver)

        Add-PSSnapin microsoft.systemcenter.virtualmachinemanager
        $vmstatus= (get-vm -Name $vm -VMMServer $vmmserver | Select-Object -Property status)
        if ($vmstatus.status -eq "running")
            {
            write-host "La VM $vm est démarré et va etre arretée"
            Shutdown-VM -VM $vm
            }
            elseif ($vmstatus.status -eq "PowerOff")
            {
            write-host "La VM  $vm est déja arrétée"
            Exit
            }
        } -Argumentlist $vm,$vmmserver
}
}       

##################################

Dans ce script qui recherche dans un fichier “VMToStop.txt” une liste de machine virtuelles a arrêter, un bloc de commande est executé a distance (Invoke-Command -ComputerName $vmmserver -ScriptBlock { } ) sur un serveur scvmm. Comment faire en sorte que les commandes executées a distance connaissent les variables locales $vm et $vmmserver ?

param($vm,$vmmserver) va permettre de declarer une liste de variable dans le ScriptBlock

-Argumentlist $vm,$vmmserver va permettre de faire la liaison entre le contenu de param et les variables locales.

A noter que le nom des variables déclarées par param est arbitraire, mais il est nécéssaire que ces variables soit dans le meme ordre que celles de –Argumentlist .

La console Web ECP permet à l’utilisateur certaines actions.

Cette console “embarque” une fonction qui n’est pas visible par défaut : Console de performances.

Cette console permet de mesurer la performance depuis votre client Web et les services

de messageries .Elle pourra vous aider à réaliser certains diagnostics.

Pour activer cette console il faut apporter une modification au fichier web.config situé

dans le répertoire …..\Exchange Server\V14\ClientAccess\ecp

   <!-- Set ShowPerformanceConsole to "true" to show ECP's Perf Console: –>

          <add key="ShowPerformanceConsole" value="false" />

Changer la valeur ShowPerformanceConsole de false à true.

Redémarrer IIS (iisreset /noforce).

Lancer la console ECP : https:\\monserveur.exchange.fr\ecp

*****************                 Rappel : avant la modif:              **************************

***********************************************************************************************

Un nouveau menu est disponible:

Cliquez sur “Console de performance”.

A la première ouverture il y a de fortes chances de voir ces quatre premiers compteurs.

Selon les outils que vous utilisez dans la console ECP d’autres compteurs seront listés:

Les données peuvent être exportées vers Excel en cliquant simplement sur “Copier”.

Bonne utilisation.

Pour ceux qui sont amenés à faire du troubleshooting sur les dossiers publics avec Exchange 2010.

Microsoft leur fournie un outil de troubleshooting assez complet nommé ExFolders.

Cet outil remplace PFDAVAdmin utilisé pour Exchange 2000/2003.

Nous savons que Les tâches d’administration peuvent être faites avec la console graphique ou les cmedlets Get-PublicFolder* , Set-PublicFolder*et add-PublicFolder* etc..

Pourquoi utiliser alors Exfolders ?

Exfolders offre aux administrateurs :

• Une console d’administration complète à l’inverse de celle par défaut qui n’est pas très pratique pour une utilisation quotidienne.
• Propager des ACE (Access Control Entry) sans écraser les ACL existantes
• Réparer des DACL endommagées sur les publics folders dans le cas ou on a des erreurs sur la console Exchange , exemple ci-dessous.

• Import & Export des permissions (utile lors d’une migration inter-forêt)
• Import & Export de la liste des réplicas
• Diagnostiquer les problèmes de publication Free/busy
• Diagnostiquer des problèmes de génération OAB (dans le cas ou vous avez encore Outlook 2003).
• Import & export des propriétés d’un dossier (ExchangeLegacyDN,PR_Replica_Server..)

Exemple ci-dessous: Export des propriétés d’un dossier

• La possibilité de se connecter à plusieurs bases de données : utilse dans le cas ou on compare deux bases de données publics.
• Contrôler vos réplicas et les permissions :

L’outil est disponible en téléchargement à l’adresse suivante :

http://gallery.technet.microsoft.com/Exchange-2010-SP1-ExFolders-e6bfd405

La Team Exchange en parle : http://blogs.technet.com/b/exchange/archive/2009/12/04/3408943.aspx

Dans une infrastructure Exchange 2010 comportant encore des dossiers publics, il est judicieux de contrôler l’accès à ces dossiers et plus précisément le referral .

dans le cas ou vous perdez votre serveur dossiers publics, comment les utilisateurs sont redirigés vers un autre réplica et selon quel critère ?

Expliquons d’abord le terme Referral avant de renter dans les détails ;) ?

Quand un utilisateur accède à un dossier Public en utilisant un client MAPI comme Outlook , Exchange va déterminer quel réplica doit être utilisé par ce client .

Ce processus est appelé REFERRAL.

Comment fonctionne le REFERRAL ?

1. Le Client MAPI se connecte à la boites aux lettres de l’utilisateur et à la Public folder Database qui est affectée à la Mailbox Database hébergeant la boite aux lettres.

2. Le client MAPI tente de lire le contenu du dossier voulu par l’utilisateur , si le réplica est disponible , le processus est terminé.

3. Si le réplica n’est pas disponible ,par défaut Exchange retourne une liste de réplicas :

Le mécanisme par défaut pour déterminer le meilleur réplica se base sur les coûts des liens intersites (Sites & Services Active Directory\Inter-site Transports\IP)

· Il va commencer par rechercher en local s’il y a une Public Folder Database qui a le contenu demandé(replica).

· Sinon , une liste de serveurs d’autre site AD est construite trié par coût (de plus petit au plus grand)

Remarque : le Coût utilisé est le coût du lien Intersite entre le serveur Mailbox de l’utilisateur et le serveur Mailbox Cible contenant le réplica)

Cette liste est retournée au client Outlook , celui-ci tente de se connecter aux Réplicas en suivant le tri.si le premier ne fonctionne pas , il passe au deuxième , ainsi de suite jusqu’à qu’à ce que la connexion soit réussie.

Dans certain cas, par exemple :

· Quand La topologie de réplication AD ne correspond pas à la topologie physique du réseau.

· Quand l’entreprise filtre les flux MAPI entre les différents sites .

il est nécessaire de contrôler le Referral pour éviter que nos utilisateurs reçoivent des messages d’erreurs , ou aient un accès dégradé aux dossiers publics.

Comment contrôler le REFERRAL ?

On peut forcer Exchange à retourner un Referral spécifique en attribuant des coûts à des serveurs Exchange comportant des dossiers publics.

Il suffit de suivre la procédure ci-dessous :

Un autre exemple avec 3 serveurs Mailbox hébergeant des dossiers Publics :

Si la Base Pub001 est en échec , Outlook utilisera en priorité le serveur 502 ensuite le 503.

Si la base Pub002 est en échec, Outlook utilisera en priorité le serveur 501 ensuite le 503.

Si Pub003 est en échec, Outlook utilisera en priorité le serveur 501 ensuite le 502.

Quelques informations complémentaires :

Microsoft Exchange 2010  - Understanding Public Folder Referrals :

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

Managing Public folder :

http://technet.microsoft.com/en-us/library/cc788135(v=exchg.80).aspx

How public folder referrals have changed in Exchange 2007

http://blogs.technet.com/b/exchange/archive/2007/03/15/3401587.aspx

La mise en place de la délégation RBAC pour Exchange 2010, peut être un casse-tête pour les consultants Exchange.

Plus il y a d’équipes qui vont gérer Exchange, plus votre tâche sera ardue.

Pour rappel, Exchange 2010 introduit un nouveau mécanisme de délégation appelé RBAC (Role Based Access Control).

Je vous invite à jeter un coup d’œil sur RBAC pour ceux qui ne connaissent pas : http://technet.microsoft.com/en-us/library/dd298183.aspx

La mise en place de la délégation passe par plusieurs étapes :

1. Créer une matrice avec les différentes équipes Exchange (Groupes AD)et les rôles de chacune

Exemple :

2. Pour chaque tâche de la matrice, essayer de déterminer s’il faut utiliser un Management role Existant ou créer un management rôle spécifique.

Exemple :

3. Déterminer ensuite les scopes à créer : un scope correspond soit à une OU , DATABASE ou Server.

Exemple :

4. Dernière étape : lier les 3 composants : Goupe AD , le Management Role et le scope.

Ce lien est le MRA : Management Role Assignment.

L’ensemble de ces étapes sont faites en ligne de commande Powershell.

Exemples de commandes :

Création d’un Management Role :

Création d’un Management Scope :

Création du Role Assignment :

5. Après avoir fait vos tests , il se peut que vous ailliez besoin de revoir une configuration d’un MRA (Management Role Assisgnment ) ou d’un MR (Management Role)

Vous avez plusieurs solutions:

• les commandes PowerShell,
• Exchange Control Panel (ECP).
• RBAC  MANAGER

RBAC Manager

Une Console GUI pour RBAC est disponible en CodePlex, elle permet d’afficher, de créer et modifier des rôles Assignement, des Management rôles et des scopes en mode graphique.

Elle intègre aussi un Optath Builder qui va faciliter la création des scopes ou des MR(Management Role) très ciblés

Par exemple : toutes les boites aux lettres de l’OU Paris avec comme attribut « City » égale à « Paris » .

Cela facilitera la gestion des MRA,MR et scopes.

Exemple de Commande pour modifier une commande lié à un MR en mode commande.

Avec RBAC manager , cela revient à décocher les paramètres qui seront désactivés ;)

Quelques Captures de la console RBAC MANAGER

Role Assignements :

Management Role

Opath Builder en béta , très utile pour les scopes.

Quelques liens utiles :

Understanding RBAC : http://technet.microsoft.com/en-us/library/dd298183.aspx

RBAC Manager : http://rbac.codeplex.com/

Suite au passage d’une infrastructure Exchange 2003 vers Exchange 2010, les utilisateurs d’Office Communicator 2007 et d’Outlook 2007 ou ultérieur dont la boite a été migrée vers la nouvelle infrastructure signalent un souci de remontée d’informations de présence ainsi que d’absence de bureau : lorsqu’ils ont une rendez-vous, une réunion ou un message OOF planifié dans leur calendrier Outlook, leur statut ne change pas automatiquement dans le client Communicator et leurs contacts ne sont donc pas prévenus de leur indisponibilité.

Par ailleurs, le client Communicator signale une erreur dans ses notifications (icone du point d’exclamation rouge sur dossier) et précise le message d’erreur   “Office Communicator n'a pas pu récupérer le calendrier ou les informations d'absence du bureau à partir des services Web Exchange” ("Communicator could not retrieve calendar or Out of Office information from Exchange Web Services") lorsque l’on clique sur la notification :

Si votre configuration EWS est vérifiée et que vous êtes certains de son exactitude, le problème provient alors probablement d’une version trop ancienne du client Communicator.

Microsoft a reconnu ce problème dans la KB 2172695 et a mis à disposition un hotfix qui couvre normalement ce problème, inclus dans le dernier pack de mises à jour disponible : http://support.microsoft.com/kb/2300255
(NB : il s’agit d’un hotfix pour le client Communicator, qui doit par conséquent être déployé sur tous les postes clients. La partie serveur Office Communication Server n’est pas concernée par ce correctif)

Pour mémoire, le processus de récupération des informations de présence par le client Communicator n’est pas instantané : il n’a lieu par défaut que toutes les 30min (à +/10min pour éviter que toutes les requêtes se fassent simultanément ce qui surchargerait les serveurs).  
Il est donc normal que le statut de présence ne soit pas mis à jour immédiatement après application du correctif ou lors de la création d’un rendez-vous “de test” dans Outlook!
Cependant, la notification d’erreur doit avoir disparu; et il est possible de forcer le rafraichissement du statut de présence en quittant puis relançant le client Communicator après la création d’un rendez-vous dans Outlook.

Bien que ce sujet puisse sembler dépassé, il peut en réalité encore servir aujourd’hui précisément dans le cadre d’une migration Exchange 2003 vers Exchange 2010 (par exemple pour ne migrer que les utilisateurs disposant d’une version d’Outlook supérieure ou égale à la 2007).

Il n’est pas possible de retrouver cette information directement à l’aide d’un cmdlet Powershell pré-existant, mais une requête WMI (classe Exchange_Logon du namespace root\MicrosoftExchangev2) exécutée via Powershell le permet :

Get-wmiobject -class Exchange_Logon -Namespace ROOT\MicrosoftExchangev2 -ComputerName ServerA -filter "LoggedOnUserAccount != 'NT AUTHORITY\\SYSTEM'" | select-object MailboxDisplayName,ClientVersion

La commande précédente permet donc de lister la version du client utilisée par chaque utilisateur pour se connecter.
On remarque qu’elle est nécessairement ciblée sur un serveur Exchange 2003 spécifique (-ComputerName ServerA).

Cependant, dans le cas où Exchange est configuré en cluster, il faut obligatoirement interroger le noeud actif pour obtenir cette information.
Il peut donc s’avérer utile de retrouver quel est le nœud actif d’un cluster à l’aide d’un script, encore une fois via WMI et Powershell (classe mscluster_nodetoactivegroup du namespace root\mscluster) puisque là non plus, Powershell ne permet pas nativement de retrouver cette information :

Get-WmiObject –ComputerName NomVirtuelduCluster –Namespace\root\mscluster –class mscluster_nodetoactivegroup  | select groupcomponent,partcomponent

Afin de ne conserver de ce résultat que la partie qui nous intéresse, à savoir le nom du noeud actif à proprement parler, on utilise la commande suivante :

$activenode = (( Get-WmiObject -ComputerName $myLegacyExchangeCluster -Namespace root\mscluster -Class mscluster_nodetoactivegroup -ErrorAction SilentlyContinue | Where-Object { $_.PartComponent -like "*Exchange Group*" } ).GroupComponent ).Split('"')[1]

Il ne reste alors plus qu’à réintégrer cette valeur à la première commande via le paramètre  –ComputerName $activenode afin d’obtenir un fonctionnement automatisé.

Lors du déploiement d’un management pack dont les découvertes sont basées sur des scripts locaux (par exemple Exchange 2010) dans SCOM 2007 R2 dans un environnement où les serveurs sont protégés par McAfee VirusScan Enterprise, les services concernés ne sont pas découverts et leur état n’apparait donc pas dans l’écran Supervision de SCOM.

En parallèle, des processus cscript.exe tournent sans fin sur les serveurs concernés et des alertes « Workflow Initialization Failed to start a workflow that runs a process or script » remontent dans SCOM :

Des erreurs cscript.exe sont également enregistrées dans l’Application Event Log de Windows sur les serveurs où se trouvent les services et applications qui devraient être découverts :

Ce problème est lié au module ScriptScan de McAfee VSE en version 8.8 qui se comporte de façon assez inattendue : lorsqu’il est désactivé, il empêche malgré tout l’exécution des scripts (dont ceux nécessaires à la détection des composants que SCOM cherche à monitorer) et ce même si les exclusions adéquates sont positionnées.

Trois solutions sont alors disponibles :

• Activer le module ScriptScan
• Complètement désinstaller la fonctionnalité ScriptScan en désenregsitrant la dll SCRIPTSN.dll sur chaque serveur :
  cd "C:\Program Files\Common Files\McAfee\SystemCore"
  regsvr32.exe /u SCRIPTSN.dll
• Déployer la version 8.8 patch 1 mise à disposition par McAfee.

C’est bien entendu cette dernière solution qu’il faudra privilégier. Pour plus de détails sur ce blocage, McAfee a également publié une KB à ce sujet : https://kc.mcafee.com/corporate/index?page=content&id=KB71660