PI Services

Voici un script de resolution d’alertes indésirables qui utilise:

1- une expression reguliere pour filtrer certains champs d’alertes

2 – une declaration switch pour prendre en charge des filtres de maniere plus pratique qu’avec if…else.

#Fermeture de certaines alertes#>

<#modifiez et/ou Incrementez les variables alertes pour prendre en charge d’autres noms d’alertes#>

$Alert1="The previous system shutdown (le dernier arret systeme n'etait pas prévu)"

$Alert2="Redemarrage Propre du serveur"

$Alert3="Database Backup Failed To Complete"

$Alert4="Network interface failed."

<#modifier $MachinePattern avec une autre expression reguliere. Ici par defaut

on recherche les alertes générées par une machine dont le nom contiens la chaine “TEST”#>

$MachinePattern="^.*(TEST).*$" 

#Initialisation du provider SCOM

add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin -erroraction silentlycontinue;

set-location "OperationsManagerMonitoring::" -ErrorVariable errSnapin;

new-managementGroupConnection -ConnectionString:monserveurscom.home -ErrorVariable errSnapin;

set-location monserveurscom.home -ErrorVariable errSnapin;

#Verification du  chargement du provider SCOM

if ($errSnapin.count -eq 0){

Write-host "`nOpsMgr 2007 PSSnapin initialized!`n";

}

else{

Write-host "`nOpsMgr 2007 PSSnapin failed initialize!`nPlease verify you are running this script on a OpsMgr 2007 Management Server";

}

$AllOpenAlert=get-alert | where-object {$_.ResolutionState -eq "0"}

Foreach ($alert in $AllOpenAlert)

{

    switch($alert)

    {

        {$_.Name -eq $Alert1 -OR $_.Name -eq $Alert2 -AND $_.MonitoringObjectName -match $MachinePattern -AND $_.LastModified -lt [DateTime]::Now.Adddays(-1)}  {resolve-alert -Alert $_ ; write-host -NoNewline $_.Name "SUR" $_.MonitoringObjectName " -- "}

        {$_.Name -eq $Alert3 -OR $_.Name -eq $Alert4 -AND $_.MonitoringObjectPath -match $MachinePattern -AND $_.LastModified -lt [DateTime]::Now.Adddays(-1)}  {resolve-alert -Alert $_ ; write-host -NoNewline $_.Name "SUR" $_.MonitoringObjectPath " -- "}

       default {break}

    }   

}

L’objectif de ce tutoriel est de réaliser un package MSI multi-langues à partir de plusieurs MSI de différentes langues. InstallSite et Microsoft fournisse leur propre méthode à base de vbscript. Ici nous utiliserons InstEd.

Dans notre cas présent, nous avons 4 MSI de 4 langues. Nous en garderons un qui servira de référence. Ensuite, nous modifions le MSI de référence pour le rendre multi-langues. Nous générons les MST de chacune des langues. Finalement, nous les stockons dans le MSI de référence.

1. Rendre un MSI multi-langues

• Ouvrir le MSI de référence avec InstEd
• Parcourir le menu Tables/Summary info…
• Ajouter au champ « Languages » les langues à venir, par leur LangID et séparer par des virgules.

2. Générer les MST

• Ouvrir le MSI d’une langue
• Parcourir le menu Transform/Generate Against…
• Sélectionner le MSI de référence
• Enregistrer le différentiel dans un MST. Garder le nom de la langue dans le nom de fichier peut aider à s’organiser.

Répéter ces actions autant de fois que vous avez de langues différentes.

3. Stocker les MST dans le MSI de référence

• Ouvrir le MSI de référence
• Ajouter un enregistrement à la table _Storage en choisissant le MST d’une langue en guise de donnée et le LangID du MST pour le nom.

Il est important de respecter cette convention de nommage car c’est une clé du mécanisme Windows Installer permettant de charger le MST correspondant à la langue de l’utilisateur (UserLanguageID ) à l’exécution du MSI.

Répéter ces actions autant de fois qu’il y a de langues. En n’oubliant pas que chaque MST ajouté doit avoir sa LangID associée ajouté au champ « Languages » dans « Summary Info ».

Voilà, c’est fini.

L’objectif est de récupérer les variables d’environnement de l’utilisateur en cours d’installation d’un package MSI. La difficulté est que l’installation par certain outil de télédistribution installent les packages avec le compte système.

Ci-joint vous trouverez un script vbs permettant de récupérer ces informations. Nous allons décrire les actions suivantes :

• Ajout du vbscript dans une « custom action »
• Séquencer cette « custom action »
• Modifier l’installation d’un composant en fonction d’une variable utilisateur
• Séquencer cette « custom action »
• Utilisation de cette nouvelle valeur dans le chemin d’installation du composant

1. Créer une nouvelle « custom action » pour exécuter le vbscript

• Ouvrir le MSI avec InstEd
• Ajouter un nouvel enregistrement dans la table CustomAction, de type 38 (0x26 - VBScript - Source: Null - Target: script text | Scheduling: Always).
• Recopier le contenu du script ci-joint dans le champ Target.

Par exemple :

Voici les variables d’environnement récupérées et les variables « windows installer » affectées :

2. Séquencer la « custom action »

• Dans la table InstallExecuteSequence, ajouter un nouvel enregistrement. La séquencer juste après InstallInitialize.

Par exemple :

3. Créer une nouvelle « custom action » pour modifier les composants à partir des nouvelles informations

• Ajouter un nouvel enregistrement dans la table CustomAction, de type 35 (0x23 - Directory - Source: Directory to be set - Target: formatted text | Scheduling: Always).

Cette « custom action » va donc affecter au répertoire « LogonUserProfile » la variable windows installer « LogonUserProfile »

4. Séquencer la « custom action »

• Dans la table InstallExecuteSequence, ajouter un nouvel enregistrement.
• Positionné la “custom action” juste après la précédente et avant l’action ProcessComponents.

Pas de condition à ajouter, car elle doit être exécutée dans tous les cas, installation, rollback, désinstallation et auto-réparation.

Par exemple :

Par exemple, ici nous avons positionné un fichier dans le profil de l’utilisateur. Ce fichier est contenu dans un composant :

Le chemin d’installation du composant sera donc automatique réévalué à l’installation, rollback, désinstallation et auto-réparation.

Ce principe pourra également être utilisé pour des package MSI x86/x64 pour des composants nécessitant un chemin différent suivant l’architecture du poste de travail.

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

Get_LogonUsersVars.vbs

Option Explicit

Const HKEY_USERS = &H80000003

Dim strKeyPath, subKey, arrKeys

Dim oReg
Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")

Dim oShell
Set oShell = CreateObject("Wscript.Shell")

strKeyPath = "Volatile Environment"

'*** DEBUT DU MAIN ***

oReg.EnumKey HKEY_USERS, "", arrKeys
  
For Each subkey In arrKeys    
    
     If RegExists("HKEY_USERS\" & subkey & "\" & strKeyPath & "\") Then

    Session.Property("LogonUserSID") = subkey

    'Msgbox "User's SID : " & Session.Property("LogonUserSID")

    Session.Property("LogonUserName") = oShell.RegRead("HKEY_USERS\" & subkey & "\" & strKeyPath & "\USERNAME")

    'Msgbox "LogonUserName : " & Session.Property("LogonUserName")

    Session.Property("LogonUserAppData") = oShell.RegRead("HKEY_USERS\" & subkey & "\" & strKeyPath & "\APPDATA")

    'Msgbox "LogonUserAppData : " & Session.Property("LogonUserAppData")

    Session.Property("LogonUserProfile") = oShell.RegRead("HKEY_USERS\" & subkey & "\" & strKeyPath & "\USERPROFILE")

    'Msgbox "LogonUserProfile : " & Session.Property("LogonUserProfile")

                
     End If
 
Next     

'*** FIN DU MAIN ***

' Test d'existence d'une clé de registre
Function RegExists(value)

    On Error Resume Next

    Dim Val
            val = oShell.RegRead(value)

    If (Err.number = -2147024893) or (Err.number = -2147024894) Then
        RegExists = False
    Else
        RegExists = True
    End If

End Function

Vous aviez sur votre poste Windows 7 et vous venez d’installer Windows 8 sur une seconde partition.

Windows 8 étant le dernier système d’exploitation à avoir été installé, vous serez donc confronté au bootloader de Windows 8. Cependant, la procédure de démarrage de Windows 8 détient une petite subtilité. Contrairement au gestionnaire de boot de Windows 7, celui de Windows 8 ne sera affiché qu’après chargement de ce nouvel OS.

Cela signifie que si vous souhaitez démarrer sous Windows 7, l’ordinateur va alors de nouveau redémarrer pour booter sur Windows 7. Cette situation peut être contraignante en termes de temps.

Nous allons donc voir comment remettre le BootLoader de Windows 7.

Démarrons par exemple sous Windows 8. (La méthode fonctionne également sous Windows 7)

Dans notre explorateur, on peut voir que la partition C : correspond à notre Windows 8.

Sur la partition D : est donc présente l’installation de Windows 7.

Ouvrez une commande cmd avec les droits administrateurs.

Tapez :

bcdboot d:\windows

(d: étant la partition hébergeant Windows 7)

la réponse suivante s’affiche

Les fichiers de boot viennent alors de se mettre à jour.

Maintenant en redémarrant,

Le bootLoader de Windows 7 est désormais restauré.

On a souvent besoin de connaitre les permissions affectées à une boite aux lettres.

Le script ci-dessous permet d’obtenir les droits mis en place par un administrateur

(send as , send on behalf, full access) ainsi que les droits donnés par l’utilisateur

via Outlook.

Voici le résultat:

Le script peut s’utiliser de deux façons.

Utilisation en indiquant un argument:

./getmailboxperm.ps1 jean@domaine.fr
 
Utilisation avec une invite de saisie:

Il faut bien entendu adapter le script au choix souhaité.

Bonne utilisation.

############################################################################
# Affiche les droits spécifiques sur une boites ainsi que les autorisations MAPI Exchange 2010
#############################################################################
 
 
#/*MBX Permission*/

#/*Utilisation avec argument (exemple) : ./getmailboxperm.ps1 pascal@domaine.fr

#$Email=$Args[0]
 
#/*Utilisation avec une invite de saisie

$Email = read-host -prompt "Entrez l'adresse de messagerie "
 
[string]$Mailbox = Get-Mailbox -Identity $Email
 
Write-Host

Write-Host "*******************************************************************************" -foregroundcolor yellow
Write-Host "*********** Autorisation sur la boite de $Email" -foregroundcolor red
Write-Host "*******************************************************************************" -foregroundcolor yellow
Write-Host

#/*Full Access*/
$FullAccess = Get-MailboxPermission $Email | where { ($_.AccessRights -eq "FullAccess") -and ($_.IsInherited -eq $false)  -and -not ($_.User -like "NT AUTHORITY\SELF") } | Select User
Write-Host "Contrôle TOTAL:" -foregroundcolor Green
Write-Host
Foreach ($User in $FullAccess)
  {
   Write-Host $User.User
  }
Write-host
#/*Send As*/
#Get-ADPermission -Identity $Sam | Where {$_.ExtendedRights -like "Send-As" -and $_.User -notlike "NT AUTHORITY\SELF" -and $_.Deny -eq $false} | ft Identity,User,ExtendedRights,IsInherited
$SendAs = Get-ADPermission -Identity $Mailbox | Where {$_.ExtendedRights -like "Send-As" -and $_.User -notlike "NT AUTHORITY\SELF" -and $_.Deny -eq $false} | Select User
Write-Host "Envoyer en tant que (send as):" -foregroundcolor Green
Write-host
Foreach ($User in $SendAs)
  {
   Write-Host $User.User
  }
Write-Host
#/*Send on Behalf*/
#$SendOnBehalf = get-mailbox -Identity $Email | Select GrantSendOnBehalfTo
$SendOnBehalf = get-mailbox -Identity $Email | Select @{Name="SendOnBehalf";Expression={$_."GrantSendOnBehalfTo"}}
Write-Host "Envoyer de la part de:" -foregroundcolor Green
Write-Host
Foreach ($User in $SendOnBehalf)
  {
   Write-Host $User.SendOnBehalf
  }
Write-Host
#/*MailboxFolders*/
$folders = Get-MailboxFolderStatistics -Identity $Email | Where {$_.Foldertype -ne "SyncIssues" -and $_.Foldertype -ne "Conflicts" -and $_.Foldertype -ne "LocalFailures" -and $_.Foldertype -ne "ServerFailures" -and $_.Foldertype -ne "RecoverableItemsRoot" -and $_.Foldertype -ne "RecoverableItemsDeletions" -and $_.Foldertype -ne "RecoverableItemsPurges" -and $_.Foldertype -ne "RecoverableItemsVersions" -and $_.Foldertype -ne "Root"} | select folderpath
 
Write-Host "Dossiers de la boîte :" -foregroundcolor Green
Write-Host
Foreach ($Folder in $folders)
  {
   Write-Host $Folder.Folderpath
  }
Write-Host
 
#/*MAPI Permissions*/
Write-Host "MAPI Permissions:" -foregroundcolor Green
Write-Host
get-mailboxfolderpermission -identity $Email":\" | ft foldername, User, AccessRights
Foreach ($Folder in $folders)
  {
   $NormalizedFolder = $Folder.FolderPath.Replace("/","\")
   $NormalizedIdentity = $Email + ":" + $NormalizedFolder
   get-mailboxfolderpermission -identity $NormalizedIdentity | ft foldername, User, AccessRights
  }

Lors de l’installation de Lync Server 2010 sur un serveur exécutant Windows Server 2008 R2 SP1, un erreur peut se produire sur le composant Wmf2008R2:

Pour cibler cette erreur, vous pouvez explorer le fichier de log mais ce dernier ne nous avance pas sur la raison de cette erreur:

Apres quelques recherches, il s’avère que l’installeur Lync server 2010 n’arrive pas a localiser Microsoft Windows Média Format et de ce fait ne réussi pas a l’installer.

Afin de palier a cette erreur vous devez installer manuellement Windows Media Format. Pour cela suivez les étapes suivantes:

1. Server Manager
1. Add Features
2. Select Desktop Experience option
3. Click Next, and then click Install

Une fois l’installation réaliser, le redémarrage du serveur est nécessaire.

Une fois le serveur redémarrer, relancer l’installation de lync Serveur. L’erreur est maintenant corriger et l’installation peut se poursuivre.

Microsoft a répertorié cette erreur sous la KB2522454

http://support.microsoft.com/kb/2522454

Microsoft met à disposition un utilitaire très utile qui permet d’obtenir des informations

sur les objets de l’annuaire.

Un premier exemple, recherchons les comptes qui n’ont pas été utilisés depuis plus de

quatre semaines du domaine courant :

dsquery user domainroot -name * -inactive 4

"CN=Jean AIMARRE,CN=Users,DC=lab,DC=ad"

On peut varier l’affichage, ici par UPN

dsquery user domainroot -name * -inactive 4 -o upn

jean.aimarre@lab.ad

Un second exemple pour retrouver les comptes désactivés dont le champ name commence

par ar :

dsquery user domainroot -o upn -name ar* –disabled

ronald.ardon@lab.ad

Un dernier exemple, on recherche le DC maitre de schéma:

dsquery server -forest -hasfsmo schema

"CN=DC1,CN=Servers,CN=Siege,CN=Sites,CN=Configuration,DC=lab,DC=ad"

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

On peut faire des requêtes sur les utilisateurs,les groupes,les contacts,les OUs,les sites,

les serveurs,les ordinateurs,les quotas et les partitions.

Pour plus d’informations: http://technet.microsoft.com/fr-fr/library/cc725702(v=ws.10)

Lors de la publication Outlook Web App sur TMG 2010, le choix de rediriger l’url HTTP

automatiquement vers une url sécurisée HTTPS est souvent retenue.

La technique retenue est souvent mise en œuvre par une première règle en “deny”

qui redirige sur la règle autorisée sécurisée.

Malgré tout, vous pourrez en fonction de ce qui est installé sur le serveur être

surpris que cette “mécanique” ne fonctionne pas .

Si vous lancez une URL de type http://monwebmail.fr , il ne se passera rien (pas de code

retour http).

C’est le cas si vous installez le rôle Exchange 2010 EDGE avec TMG 2010.

Dans le journal d’évènement Windows ou TMG vous verrez ce type d’erreur après

le démarrage du service TMG FireWall :

Cela indique que TMG ne peut “lier” une règle sur le port 80 car celui-ci est

déjà lié à un autre service !

En lançant la commande netstat on remarque bien que le port 80 n’est pas lié

à l’adresse IP définie dans la règle de TMG:

utilisez un utilitaire comme NETSH (netsh http show servicestate) ou ProcessViewer

pour déterminer le “coupable”.

Dans mon cas par défaut l’installation du EDGE installe le composant IIS.

Il suffit d’arrêter le service “World Wide Web Publishing Service” et de le désactiver

puis de relancer le service TMG FireWall.

Vérifiez avec NETSTAT:

L’adresse IP définie dans la règle “DENY” est maintenant liée au port 80 et en écoute.

La requête HTTP peut donc maintenant être rediriger vers la règle HTTPS.

Une session SMTP renvoie certaines informations et plus particulièrement le nom

du serveur que l’on souhaite dans certains cas modifier.

Sous Exchange 2010 les informations renvoyées par la connexion (220) et par l’initialisation

de la session (helo, 250) sont “personnalisable”.

Voici un aperçu typique par défaut:

Pour modifier les informations renvoyées  par la connexion (220) il faut utiliser une commande PowerShell.

Affichons la configuration initiale (par défaut):

L’attribut “Banner” est vide , malgré tout des informations par défaut sont renvoyées.

(Ligne 1 ).

L’attribut “Fqdn” qui est renvoyé après le “helo” à par défaut le nom DNS du serveur.

(Ligne 2 ).

Modifions l’information renvoyé à la connexion:

Set-ReceiveConnector "MyConnector" -Banner "220 Welcome"

Modifions l’information renvoyé après la commande “helo”:

Set-ReceiveConnector “MyConnector" -Fqdn "PostFix.fr"

(Cette dernière configuration peut être modifiée dans l’interface graphique).

Ce qui donne:

Lors de l’utilisation de scanstate (outil USMT), il se peut que vous ayez des problèmes d’accès sur certains profils. Cela peut se produire quand un profil sur l’ordinateur n’a pas été supprimé proprement.

Par exemple un profil utilisateur a été supprimé depuis l’explorateur et non depuis les paramètres système avancés è Profil des utilisateurs .

Dès que cela se produit, le mécanisme par défaut de USMT tente sous 20 reprises de charger le NTUSER.dat de ce profil non trouvé.

Cela a pour cause de prolonger le temps de traitement de scanstate.

Pour désactiver les tentatives répétés d’accès à des profils supprimé, une variable peut être définit : MIG_IGNORE_PROFILE_MISSING

Il suffit de définir cette variable à 1 et l’outil Scanstate ne tentera plus d’accéder de manière répété aux profils absent : SET MIG_IGNORE_PROFILE_MISSING=1