PI Services

Avec certains système de messagerie nous pouvons envoyer un

message en utilisant une session “telnet” avec la syntaxe suivante:

220 monserveur.fr Microsoft ESMTP MAIL Service ready at Wed, 9 May
helo
250 monserveur.fr Hello [10.10.10.10]
mail from: john@track.ru
250 2.1.0 Sender OK
rcpt to: p.fedan@mondomaine.fr
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
subject: Test email using telnet
Ceci est un test.
.
250 2.6.0 7b45f718-0d0c-42fd-b2f4-dd3607bb334b@monserveur.fr

On remarque qu’avec Exchange 2010 le destinataire et le corps du

message sont vides !

La syntaxe utilisée doit être la suivante:

220 monserveur.fr Microsoft ESMTP MAIL Service ready at Wed, 9 May
helo
250 monserveur.fr Hello [10.10.10.10]
mail from: john@track.ru
250 2.1.0 Sender OK
rcpt to: p.fedan@mondomaine.fr
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
to: p.fedan@mondomaine.fr         ######## Ajouter le champ “to”
Subject: test 2 email using telnet   ####### Insérer un saut de ligne

Ceci est un test.

.
250 2.6.0 <6a990d2b-9118-4e5c-8c4d-a7b70b382813@monserveur.fr

L’expéditeur et le corps du message seront présent:

Symptômes :

- Sur un serveur Windows 2008 R2 il peut arriver que lorsqu’on ouvre la console « Gestionnaire du serveur », les onglets Rôles et features soient en Erreur » avec un code erreur 0x800B0100

- Dans Panneau de configuration, Programs-> Programs and features, les mises à jour installées n’apparaissent plus.

Cause :

Une mise à jour mal installée avec des packages manquants ou corrompus.

Solution :

Cibler le ou les packages incriminés et les réinstaller, pour cela il faut suivre les étapes suivantes :

• Télécharger l’outil « System Update Readiness Tool for Windows Server 2008/Vista : Il faut choisir la version correspondant à l’architecture du serveur : x86 ou x64 bits
• Executer l’outil
• Un fichier de log est généré automatiquement dans C:\Windows\logs\CBS\CheckSUR.log , voici un exemple de fichier log

Dans ce cas et qui peut être différent d’un serveur à un autre, la mise à jour KB2506014 avait 2 packages corrompus et qui ont été corrigé et remplacé automatiquement.

Il peut arriver que des packages soient manquants dans ce cas il faut :

• Télécharger la KB.msu
• Renommer.msu en .cab et extraire tous les fichiers pour récupérer les packages manquants.
• Copier ces packages dans un nouveau dossier
• Modifier le propriétaire du dossier C:\Windows\Servicing\Packages, en le remplaçant avec le compte que vous utilisez
• Donner les droits « full control » pour le compte que vous utilisez

• Copier les packages dans le dossier C:\Windows\Servicing\Packages
• Ne pas oublier de réattribuer le droit « Propriétaire » à l’utilisateur initial.

Le module PowerShell de Windows offre la possibilité d’automatiser l’installation de SharePoint 2010. Voici les étapes à suivre :

• Récupérer la clé de License du produit.
• Télécharger le module SPModule qui est un module Windows PowerShell qui installe une batterie de serveur SharePoint (un .zip + fichier.txt)
• Extraire les fichiers dans un dossier (le .zip contient 2 dossiers :SPModule.misc et SPModule.setup)
• Activer l’exécution des scripts Power shell en exécutant la cmdlet suivante : Set-Executionpolicy Unrestrited

• Importer le module SPModule dans PowerShell : il faut exécuter Windows PowerShell en mode Administrateur puis lancer les cmdlets suivantes :

• Créer un fichier .XML qui contiendra tous les paramètres de configuration : « sharepointInstall_config.xml »

  <Configuration> <Package Id="sts"> <Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes"/> </Package> <Package Id="spswfe"> <Setting Id="SETUPCALLED" Value="1"/> <Setting Id="OFFICESERVERPREMIUM" Value="1" /> </Package> <Logging Type="verbose" Path="%temp%" Template=" Setup(*).log"/> <PIDKEY Value="PKXTJ-DCM9D-6MM3V-G86P8-MJ8CY" /> <Setting Id="SERVERROLE" Value="APPLICATION"/> <Setting Id="USINGUIINSTALLMODE" Value="1"/> <Setting Id="SETUP_REBOOT" Value="Never" /> <Setting Id="SETUPTYPE" Value="CLEAN_INSTALL"/> <INSTALLLOCATION Value="c:\Program Files\Microsoft SharePoint" /> <Display Level="Basic" CompletionNotice="Yes" AcceptEULA="Yes" /> </Configuration>

Détails des attributs et des arguments:

<Package Id="sts"> : ce package permet d’installler le module : SharePoint Foundation 2010 qui représente le socle de SharePoint 2010

<Package Id="spswfe"> ce package installe le modutle SharePoint 2010

<Setting Id="SERVERROLE" Value="APPLICATION"/>: permet de faire une installation d’une ferme de serveur,

<Display Level="Basic" CompletionNotice="Yes" AcceptEULA="Yes" /> :

Displey Level =”basic” : permet d’afficher les étapes d’installation , la clé du produit et les termes du contrat de License

CompletionNotice =”Yes” : Applicable uniquement si “Level” a la valeur Basic ou None. Le programme d’installation affiche l’avertissement de fin d’opération.

AcceptEULA = “Yes” : ce paramètre permet d’accepeter les termes du programme d’installation

<Logging Type="verbose" Path="%temp%" Template="SharePoint Server Setup(*).log"/>
Logging Type =”verbose” : permet d’ecrire toutes informations dans les fichiers de log , c’est le niveau de logging le plus elevé.

Path=”%temp% il s’agit du chemin par défaut pour stocker le fichier de log”.

Template =”Setup (*).log : le nom du fichier log , l’* permet au programme d’installation d’ajouter une chaine de caractère “AAAAMMJJHHMMSSxxx” afin que le fichier de log soit unique

• Lancer la cmdlet suivante :

Install-SharePoint -SetupExePath <nom et Chemin d’accès au setup.exe> -ConfigXML <nom et chemind’accès au fichier xml>

De plus en plus d’entreprise ayant choisit MOSS 2007 pour répondre à leur besoin en terme de travail collaboratif commencent à migrer vers la solution SharePoint 2010 afin de bénéficier de toutes les nouveautés et des améliorations du produit.

Microsoft propose nativement quelques méthodes de migration, chacune de ces méthodes possèdent des avantages et des inconvénients.

La migration peut être découpée en deux étapes importantes : migration de la version de l’outil SharePoint (Déploiement de SharePoint 2010 sur tous les serveurs de la ferme) et la migration du contenu du portail existant SharePoint.

Ave Point propose son outil Doc Ave SharePoint Migrator V5 permettant de migrer le contenu SharePoint d’une ferme à une autre.

Voici la liste des éléments pouvant être migrés :

• Les bibliothèques 
• Les dossiers
• Les pages Web
• Les listes
• Les différentes versions des documents (si le versionning est activé sur le site SharePoint)
• La Sécurité : utilisateurs et permissions
• Les listes personnalisées
• Les métadatas
• Les modèles de sites
• Mes Liens

Avantages de l’utilisation de cet outil :

• Minimiser les efforts requis pour le déploiement de la nouvelle version de SharePoint : puisque DocAve permet de déplacer automatiquement le contenu source vers le contenu Cible en gardant les mappages des éléments ainsi que toutes les propriétés.
• DocAve assure l’intégrité des données sensibles durant la migration.
• Réutilisation des sauvegardes SharePoint pour faciliter la migration : Lors d’une migration il est possible soit de migrer le contenu directement (en Live) soit de faire une restauration à partir de sauvegardes existantes, dans ce 2^e cas l’administrateur optimise sa productivité puisqu’il n’aura pas à recréer la structure de la plateforme.
• Permet aux administrateurs SharePoint de réussir leur Migration en évitant d’oublier des étapes à exécuter.
• Avec DocAve Migrator, la migration en direct est très simple et se base sur un simple glissé/deplacé ce qui par conséquent simplifie la migration
• Flexibilité de la migration : Avec docAve Migrator, la migration peut se faire de manière granulaire (une instance, un dossier, ou un élément…) et peut être planifiée (exécution de la tâche de migration à une heure précise).
• L’outil DocAve Migrator peut être deployé sur un matériel existant de la plateforme SharePoint existante, aucun pré requis matériel n’est obligatoire
• DocAve Migrator, utilise un scanner de pré migration afin d’éviter tout risque d’erreur.

Les ressources pouvant être migrées avec DocAve Migrator vers SharePoint 2010:

• SharePoint 2001, 2003, 2007
• Exchange Public Folder
• File Systems/Network Shares
• Documentum/eRoom
• Open Text Livelink/Vignette
• Lotus Notes/QuickPlace
• Oracle Stellent
• Static, HTTP/S accessible web content and internet sites
• Microsoft Content Management Server 2002 (MCMS 2002)

Pour rappel sous Exchange 2010 il ne suffit pas de mettre un gestionnaire

pour lui permettre de gérer un groupe de distribution:

Il faut activer le rôle défini par le mécanisme RBAC.

Cochez “MyDistributiongroups”

On constate en lançant Outlook Web App que la création de groupe

n’est pas disponible avant l’activation du rôle:

Après activation, de nouveaux menus sont disponibles:

Chaque utilisateur peut donc créer un groupe

et supprimer un groupe dont il est le propriétaire !

Ce droit “excessif” peut ne pas répondre à la stratégie de la société.

Nous allons donc retirer ces droits de création et de suppression.

Recherchons le rôle “MyDistributionGroups”

Créer un rôle enfant de “MyDistributionGroups” en supprimant le droit de créer et de supprimer un groupe.

New-ManagementRole –Name ****OwnerDistributionGroups -Parent MyDistributionGroups

On remarque la présence de ce nouveau rôle dans la console “RBAC”:

Vérifions le rôles assignés sur “Default Role Assignment Policy”

MyDistributionGroups est présent.

Supression des droits New et Remove

Remove-ManagementRoleEntry ****OwnerDistributionGroups\New-DistributionGroup -Confirm:$false

Remove-ManagementRoleEntry ****OwnerDistributionGroups\Remove-DistributionGroup -Confirm:$false

Puis il faut associer le “Default Default RoleAssignment Policy” avec ce nouveau rôle :

New-ManagementRoleAssignment –Role ****OwnerDistributionGroups -Policy "Default Role Assignment Policy"

L’opération n’est pas finie car le rôle parent est toujours assigné donc actif.

Supprimons ce lien:

Remove-ManagementRoleAssignment “MyDistributionGroups-Default Assignment Policy”

Vérifions

Ce qui donne dans la console RBAC cette configuration:

Et pour l’utilisateur final:

Les droits de création et de suppression ne sont plus disponible.

Symptômes :

Lors du rapatriement des pilotes un bug se produit et l’assistant s’interrompt (imprimante réseau couleur).

« Windows cannot connect to the printer. Operation failed with error 0x0000007e ».

Ce problème survient lorsque qu’on tente d’ajouter une imprimante couleur sur un poste client Windows 7 rattaché à un serveur d’impression Windows 2003 ou Windows 2008.

Deux solutions de contournements fonctionnent car le problème est connu par Microsoft mais sans correctif pour le moment.

· Le premier s’opère sur le poste client, et consiste à installer l’imprimante en utilisant le port LPT2, puis d’utiliser une commande de redirection

· Le deuxième consiste à modifier une clé de registre sur le serveur d’impression. Puis de se connecter à l’imprimante.

Regedit> HKLM\System\CurrentControlSet\Control\Print\Printers\printername\CopyFiles en renommant le répertoire CopyFiles par xCopyFiles. Ce répertoire n’existe que pour une imprimante couleur.

Les deux solutions fonctionnent instantanément. Mais il est beaucoup plus rapide de modifier le répertoire défaillant directement dans la base de registre pour toutes les imprimantes concernées.

Il existe un module nommé NTFSSECURITY permettant une manipulation simplifié des droits NTFS sur des dossiers et/ou fichiers.

Ce module peut être trouvé sur la galerie Technet http://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85/file/48905/1/NTFSSecurity%201.3.zip

Une fois téléchargé, mettez le dossier du module NTFSSecurity ici C:\Windows\System32\WindowsPowerShell\v1.0\Modules

Maintenant, nous allons charger le module dans powershell

Une fois celui-ci chargé, de nouvelles cmdlets sont désormais disponible.

                                    …

Récupération du SID d’un utilisateur dans une variable.

Nous allons définir dans une variable $SamMember le nom de l’utilisateur que nous voulons récupérer.

Ensuite nous allons utiliser l’object System.Security.principal.NtAccount(« domaine »,utilisateur) qui va nous permettre de récupérer notre utilisateur dans un domaine spécifié.

Maintenant, récupérons le SID de notre utilisateur grâce à une méthode de notre variable $account.

Nous avons ainsi récupéré dans notre variable $accountsid le SID de notre utilisateur spécifié dans la variable $SamMember.

Modification du propriétaire d’un répertoire.

Avec le chargement du module NTFSSecurity, une cmdlet get-owner est apparue nous permettant de connaitre simplement le propriétaire d’un élément (fichier ou répertoire).

Exemple :

Nous allons maintenant changer le propriétaire de ce répertoire avec l’utilisateur contenu dans notre variable $accountsid

Voyons maintenant le résultat :

Le propriétaire à bien été changé.

Modification des ACE du répertoire.

Nous allons maintenant modifier les ACE du répertoire de façon à ne laisser que l’utilisateur de notre variable $accountsid en FullControl et aucune autre ACE.

Rajout de l’ACE :

Suppression des autres ACE :

(Ce lien permet de connaitre les SID connu dans les OS Windows http://support.microsoft.com/kb/243330)

Si on consulte maintenant nos ACE, on peut remarquer que notre ajout d’ACE s’est bien passé mais que la suppression des autres ACE ne s’est pas déroulée correctement.

Cela est normal, car ses ACE sont hérité du répertoire parent. Il faut donc pour cela retirer l’héritage.

Et maintenant si on essaie de nouveau de supprimer nos ACE on peut remarquer que celle-ci ont bien disparu.

Il est maintenant facile d’imaginer la création d’un script pouvant réappliquer correctement des droits sur une toute une arborescence de répertoires profils en récupérant par exemple le nom du répertoire profil et en réaffectant celui-ci dans une boucle pour notre variable $account.

Ainsi, l’utilisateur authentifié en user2, ne pourra accéder qu’à son répertoire profil.

Le comportement d’USMT dans un état Offline est différent d’un état Online.

Nous nous situons dans un cas ou l’exécutable Scanstate est lancé sous Windows PE (donc offline).

Lors d’une capture en offline, le mappage des utilisateurs ne peut se baser sur la base SAM des utilisateurs. Le mappage s’effectue à l’aide des SID.

Exemple du log du ScanState sous Windows PE (Offline)

Exemple du log de ScanState sous Windows XP (Online)

Ce qui veut dire que pendant l’utilisation du ScanState sous Windows PE, nous ne devons travailler qu’avec des SID.

Si par exemple on ne veut inclure qu’un seul utilisateur dans notre DataStore du ScanState, il faudra utiliser l’argument /ue:* permettant d’exclure tous les utilisateurs et utiliser l’argument /ui  permettant d’inclure l’utilisateur spécifique avec son SID.

Exemple:

scanstate E:\Migshare\U11281 /i:x:\ftmas7\tools\usmt\F2_MigFiles.xml /i:x:\ftmas7\tools\usmt\MigOutlook.xml /o /c /localonly /v:13 /offlinewindir:c:windows /ue:* /ui:S-1-5-21-1221297486-3643808661-2871141796-1074 /l:E:\Migshare\U11281\log.txt

Pour inclure plusieurs utilisateurs, l’argument /ui peut être utilisé autant de fois que désiré.

Utilisation du ScanState en Offline pour capturer uniquement des utilisateurs du domaine.

Si vous souhaitez ne capturer que des utilisateurs d’un domaine et non les utilisateurs locaux, vous pouvez exclure tout le monde via l’argument /ue :* et inclure uniquement le SID du domaine avec l’astérique « * » pour le pool RID.

Exemple :

scanstate.exe S: /i:MigFiles.xml /i:MigOutlook.xml /l:S:\log.log /progress:S:\Prog.log /localonly /o /c /v:13 /offlinewindir:c:\windows /ue:* /ui: S-1-5-21-759407729-413330662-2607319723-"*"

Utilisation du LoadState sur un DataStore obtenu par un ScanState Offline

Contrairement au ScanState, le LoadState ne peut être exécuté qu’en mode Online.

Ayant utilisé ScanState en mode Offline, nous avons donc du traiter les utilisateurs via leurs SID. Il en sera donc de même pour le LoadState car aucun mappage samaccountname n’a pu être effectué précédemment.

Donc l’utilisation des commutateurs /ue et /ui se passent de la même manière que pour le Scanstate en Offline c’est-à-dire basé sur des SID.

Dans le cas d’une migration de domaine, il n’est pas nécessaire de spécifier le SID du domaine source vers le domaine cible. (La migration de domaine s’opère à l’aide du commutateur /md. (/md:Old_domain :New_domain)

Exemple :

loadstate F:\Migshare\U11281 /i:C:\APPLI_FTV\apps\usmt\F2_MigFiles.xml /i:C:\APPLI_FTV\apps\usmt\MigOutlook.xml /c /v:13 /l:F:\Migshare\U11281\Load-log.txt /md:SourceSI :CibleSi /progress:F:\Migshare\U11281\simpleprog.log

Cela signifie que tous les utilisateurs situés dans le DataStore avec pour domaine source « SourceSI » vont être migré sur « CibleSi » si ceux-ci existent.

Attention, si USMT tente de migrer un utilisateur sur un domaine cible mais que celui-ci n’existe pas dans ce domaine, une erreur fatale en ressortira et le déroulement du LoadState sera alors interrompu.

Cependant, si vous souhaitez utiliser /mu au lieu de /md, la, il faudra utiliser le SID utilisateur depuis la source et spécifier le domaine cible ainsi que son Sam Account Name.

Exemple :

loadstate F:\Migshare\U11281 /i:C:\APPLI_FTV\apps\usmt\F2_MigFiles.xml /i:C:\APPLI_FTV\apps\usmt\MigOutlook.xml /c /v:13 /l:F:\Migshare\U11281\Load-log.txt /mu:S-1-5-21-1221297486-3643808661-2871141796-1074:CibleSi\trsb2 /ui:S-1-5-21-1221297486-3643808661-2871141796-1074 /progress:F:\Migshare\U11281\simpleprog.log /ue:*

Le profil utilisateur sera alors créé sur l’os cible dans le nouveau domaine.

Vous disposez d’une liste exhaustive de comptes utilisateurs dans un fichier et vous désirez savoir ceux d’entre eux qui sont bien existant dans le domaine courant.

Pour cela, nous allons parcourir ce fichier et établir une connexion sur ces utilisateurs. Si la connexion sur l’utilisateur se passe bien, nous l’ajouterons dans un second fichier. Si cet utilisateur n’existe pas, nous l’ignorerons.

Exemple de fichiers contenant sur une colonne des utilisateurs existant ou non dans le domaine courant.

Résultat obtenu dans un fichier result.txt :

Le script nous a bien permit de récupérer uniquement les utilisateurs existant dans le domaine courant.

Les « tâches console » sont comme leur nom l’indique des tâches qui s’exécutent sur la console, par opposition aux tâches Agent qui sont elles exécutées sur les ordinateurs monitorés et dont le résultat est ensuite affiché dans la console.

Elles permettent de lancer un exécutable sur l’ordinateur exécutant la console, éventuellement en lui passant des paramètres récupérés dans la console.

Exemple concret : on peut ainsi lancer un ping ou une session bureau à distance automatiquement vers le l’ordinateur sélectionné dans  la console.

Je détaillerai ici le cas rencontré chez un client qui souhaitait pouvoir accéder aux incidents créés indépendamment de SCOM dans un système de gestion de tickets tiers à la suite de la remontée de certaines alertes dans SCOM.
Ce système de ticket étant accessible via un simple navigateur web sur une url fixe prenant l’ID du ticket en paramètre (ID préalablement renseignée dans un CustomField de l’alerte par le helpdesk), nous avons procédé de la sorte :

Dans la console Authoring (et non pas la vue authoring de la console Operations, cette dernière ne permet pas de créer ce genre de tâche!), créer un nouveau management pack.
Se rendre dans la vue Presentation et sélectionner Console Tasks dans le menu de gauche, puis faire un clic-droit à sélectionner New>Console Task (attention à ne pas confondre avec les Agent Tasks qui se trouvent elles dans la vue Health Model!) :

Nommer cette nouvelle tâche :

Lui donner un nom d’usage, qui apparaitra dans SCOM et choisir l’élément qu’elle ciblera :

Dans l’onglet Command Line, renseigner la partie fixe de la commande lancée par la tâche.
Dans notre cas il s’agit donc d’appeler le navigateur web et de lui passer la partie invariable de l’URL du système de gestion de tickets, mais plutôt que d’indiquer le chemin absolu vers l’exécutable du browser, nous avons choisi d'appeler le navigateur par défaut du système à l’aide du raccourci rundll32 url.dll,FileProtocolHandler http://suivi.tickets.local/?ticketID= .
Cela permet d’éviter les potentiels soucis liés à l’utilisation de navigateurs différents suivant les ordinateurs et respecte ainsi les préférences de l’utilisateur de la console SCOM.
Il faut ensuite indiquer en paramètre que l’on souhaite récupérer le CustomField de l’alerte contenant l’ID du ticket.
Oui mais… par défaut, seul le Display Name est disponible en paramètre :

Afin de modifier ce comportement, se rendre dans l’onglet Options et cliquer sur Category [Value=MonitoringObject]. Cela dévoile des options qui étaient jusque là invisibles et il est alors possible de sélectionner la catégorie Alert :

En retournant dans l’onglet CommandLine, on constate qu’il est maintenant possible de sélectionner les CustomField  comme paramètres (ainsi que bien d’autres, libre à vous d’adapter suivant vos besoins!) :

Il ne reste plus qu’à enregistrer le management pack et à le publier dans SCOM.