PI Services

Le blog des collaborateurs de PI Services

Azure - Gestion des licences par groupe avec des groupes dynamiques

Description

Pour attribuer une licence a un utilisateur de votre annuaire Azure, cela nécessite l’une des étapes suivantes :

  • Attribution de licences directement aux utilisateurs par l’intermédiaire du portail, de PowerShell ou des API.
  • Attribution de licences à des groupes dans le portail Azure.

Quand vous attribuez des licences à un groupe, tous les membres de ce groupe disposent d’une licence. Si des utilisateurs sont ajoutés au groupe ou en sont supprimés, la licence appropriée leur est attribuée ou retirée.

Vous pouvez utiliser l’attribution de licence basée sur le groupe pour configurer des règles telles que les suivantes :

  • Tous les utilisateurs de votre annuaire obtiennent automatiquement une licence
  • Toute personne avec la fonction appropriée obtient une licence

Configuration

Pour créer un groupe il faut utiliser votre compte d’administration Azure et se rendre à l’adresse suivante : https://portal.azure.com.

Une fois connecté vous devez aller dans le menu « Azure Active Directory ».

clip_image001

Créer un groupe dans le sous menu « Utilisateurs et groupes ».

clip_image002

clip_image003[4]

Puis revenir dans l’onglet « Azure Active Directory » et cette fois ci sélectionner « Licences ».

clip_image004[4]

Une fois que vous êtes dans le menu de vos licences sélectionnez le produit sur lequel vous voulez créer un groupe dynamique et cliquez sur « Attribuer ».

clip_image005[4]

Choisissez le groupe que vous avez crée et configuré le les options de la licence. Cette étape est importante car tous les utilisateur qui seront dans le groupe hériterons de ces options.

clip_image006[4]

clip_image008

Ajouter les membres

clip_image010

L’utilisateur ci-dessous hérite maintenant du groupe «DL_O365_E5»

clip_image011

Information :

Pour plus d’information concernant la configuration, je vous invite à consulter le lien suivant :

Manage Azure Active Directory licencing

SCOM – Requête SQL des agents gérés par une gateway spécifique

La requête SQL ci-dessous affiche les agents gérés par une Gateway spécifique ainsi que le failover configuré ou non.

Use OperationsManager
 
DECLARE @PrimaryServer VARCHAR(50)
SET @PrimaryServer = 'MyGateway'
 
;
 
WITH 
PrimaryRelation (SourceEntityId,agent,PrimaryServer,TargetEntityId)
AS
(
SELECT R.SourceEntityID,SourceBME.DisplayName as Agent,TargetBME.DisplayName as PrimaryServer, R.TargetEntityID
FROM Relationship R WITH (NOLOCK) 
JOIN BaseManagedEntity SourceBME 
ON R.SourceEntityID = SourceBME.BaseManagedEntityID 
JOIN BaseManagedEntity TargetBME 
ON R.TargetEntityID = TargetBME.BaseManagedEntityID 
WHERE R.RelationshipTypeId = dbo.fn_ManagedTypeId_MicrosoftSystemCenterHealthServiceCommunication() 
AND TargetBME.IsDeleted <> '1'  -- AND THE PRIMARY SERVER IS NOT WAITING TO BE DELETED
AND SourceBME.IsDeleted <> '1' -- AND THE AGENT IS NOT WAITING TO BE DELETED
)
,
FailoverRelation (SourceEntityId,agent,FailoverServer,TargetEntityId)
AS
(
SELECT R.SourceEntityID,SourceBME.DisplayName as Agent,TargetBME.DisplayName as FailoverServer, R.TargetEntityID
FROM Relationship R WITH (NOLOCK) 
JOIN BaseManagedEntity SourceBME 
ON R.SourceEntityID = SourceBME.BaseManagedEntityID 
JOIN BaseManagedEntity TargetBME 
ON R.TargetEntityID = TargetBME.BaseManagedEntityID 
WHERE R.RelationshipTypeId = dbo.fn_ManagedTypeId_MicrosoftSystemCenterHealthServiceSecondaryCommunication()
AND TargetBME.IsDeleted <> '1'  -- AND THE FAILOVER SERVER IS NOT WAITING TO BE DELETED
AND SourceBME.IsDeleted <> '1' -- AND THE AGENT IS NOT WAITING TO BE DELETED 
)
 
 
SELECT 
       MTV_HS.[DisplayName] as Agent
       
      ,PrimaryRelation.PrimaryServer
      ,FailoverServer =  -- FIELD RELATED TO 'LEFT OUTER JOIN' ON FailoverRelation TABLE
        CASE
        WHEN FailoverRelation.FailoverServer IS NULL THEN 'NO FAILOVER'
        ELSE FailoverRelation.FailoverServer
        END
      ,[Port]
      ,[InstallTime]
      ,[MaximumQueueSize]
      ,Patch = CASE 
        WHEN [PatchList] like '%UR4%' THEN 'RU4'
        WHEN [PatchList] like '%UR8%' THEN 'RU8'
        WHEN [PatchList] like '%UR11%' THEN 'RU11'
        WHEN [PatchList] = '' THEN '[NO_DATA]'
        END
      ,[IsManuallyInstalled]
      ,[Version]
      ,[ActionAccountIdentity]
      ,[ProxyingEnabled]
      ,[HeartbeatInterval]
      ,[NumberOfMissingHeartBeatsToMarkMachineDown_27AD2E30_EFE0_1A73_8C9D_F0A22B073227] as NumberOfMissingHeartBeatsToMarkMachineDown
      ,MTV_OS.DisplayName as OS
      ,MTV_OS.LogicalProcessors_5CAE4847_F75B_01D0_156E_1658D557B739 as Logic_CPU
      ,MTV_OS.CSDVersion_AFE62B62_74FC_2F06_D8A0_DEE31F14CD33 as ServicePack
      
      
  FROM [OperationsManager].[dbo].[MTV_HealthService] as MTV_HS
  INNER JOIN  [dbo].[MTV_Microsoft$Windows$OperatingSystem] as MTV_OS on MTV_HS.DisplayName = MTV_OS.PrincipalName
 
  INNER JOIN PrimaryRelation on PrimaryRelation.SourceEntityId = MTV_HS.BaseManagedEntityId
  -- THE LEFT OUTER JOIN CAN BE COMMENTED (AND RELATED FIELDS) TO DISPLAY ONLY THE PRIMARY SERVER)
  LEFT OUTER JOIN FailoverRelation on FailoverRelation.SourceEntityId = MTV_HS.BaseManagedEntityId
 
  WHERE IsAgent = '1'
  AND PrimaryServer like '%'+@PrimaryServer+'%'
 
 
  order by MTV_HS.[DisplayName]

SCOM – Requête SQL de toutes les instances d’objet pour une machine

La requête ci-dessous liste toute les instances d’objets qui se rapporte a une machine donnée, avec leur état ainsi que les infos sur un éventuel mode maintenance en cours sur l’objet.

Use OperationsManager
 
DECLARE @TargetComputer VARCHAR(50)
set @TargetComputer = 'MyServer'
 
SELECT 
MTV.DisplayName as ClassName
,MEGV.Path as Instance_Path
,MEGV.[DisplayName] as 'Entity_DisplayName'
,MEGV.[Name] as 'Entity_Name'
,MEGV.[FullName] as Entity_FullName
,[IsManaged]
,[IsDeleted]
,HealthState =                                                     
    CASE WHEN InMaintenanceMode = '0'
      THEN 
        CASE [HealthState]
        WHEN '0' THEN 'Not Monitored'
        WHEN '1' THEN 'OK'
        WHEN '2' THEN 'Warning'
        WHEN '3' THEN 'Critical'
        END
        WHEN InMaintenanceMode = '1'
        THEN 
        CASE [HealthState]
        WHEN '0' THEN 'In Maintenance Mode'
        WHEN '1' THEN 'OK'
        WHEN '2' THEN 'Warning'
        WHEN '3' THEN 'Critical'
        END
    END
 
,Is_Available = 
    CASE [IsAvailable]
    WHEN '1' THEN 'YES'
    WHEN '2' THEN 'NO'
        END
                                                  
,In_MaintenanceMode = 
CASE [InMaintenanceMode]
WHEN '0' THEN 'NO'
WHEN '1' THEN 'YES'
END
,Start_Of_Maintenance = 
    CASE WHEN InMaintenanceMode = '0' 
        THEN null
        ELSE MMV.StartTime
        END
       ,End_Of_Maintenance = 
        CASE WHEN InMaintenanceMode = '0'
                THEN null
        ELSE MMV.ScheduledEndTime
        END
        ,Maintenance_RootCause = 
            CASE WHEN InMaintenanceMode = '0'
              THEN null
                ELSE 
                CASE MMV.ReasonCode
                WHEN '0' THEN 'Other (Planned)'
                WHEN '1' THEN 'Other (Unplanned)'
                WHEN '2' THEN 'Hardware: Maintenance (Planned)'
                WHEN '3' THEN 'Hardware: Maintenance (Unplanned)'
                WHEN '4' THEN 'Hardware: Installation (Planned)'
                WHEN '5' THEN 'Hardware: Installation (Unplanned)'
                WHEN '6' THEN 'Operating System: Reconfiguration (Planned)'
                WHEN '7' THEN 'Operating System: Reconfiguration (Unplanned)'
                WHEN '8' THEN 'Application: Maintenance (Planned)'
                WHEN '9' THEN 'Application: Maintenance (Unplanned)'
                WHEN '10' THEN 'Application: Installation (Planned)'
                WHEN '11' THEN 'Application: Unresponsive'
                WHEN '12' THEN 'Application:  Unstable'
                WHEN '13' THEN 'Security Issue'
                WHEN '14' THEN 'Loss of network connectivity (Unplanned)'
                END
            END
                                               
,Maintenance_Reason =   
    CASE WHEN InMaintenanceMode = '0' 
    THEN null
    ELSE MMV.Comments
    END
      
FROM [OperationsManager].[dbo].[ManagedEntityGenericView] MEGV
INNER JOIN [dbo].[ManagedTypeView] MTV on MEGV.MonitoringClassId = MTV.Id
INNER JOIN [OperationsManager].[dbo].[MaintenanceModeView] MMV on MEGV.id = MMV.BaseManagedEntityId
WHERE (MEGV.Name  like '%'+@TargetComputer+'%' OR MEGV.DisplayName  like '%'+@TargetComputer+'%' OR MEGV.Path  like '%'+@TargetComputer+'%')
and MTV.LanguageCode = 'ENU'
and MEGV.HealthState is not null
and MEGV.IsDeleted <> '1'
ORDER BY MTV.DisplayName
 
 

SCOM – Requête des heartbeat failure pour les membres d’un groupe spécifique

La requête ci-dessous, a exécuter sur la base de reporting, liste les alertes “Health Service Heartbeat Failure” pour les membres d’un groupe donné (@computergroup1) sur une plage de temps donnée.

-- QUERY TO GET 'Health Service Heartbeat Failure' ALERTS FOR COMPUTERS THAT ARE MEMBERS OF A SPECIFIC GROUP (@computergroup1)
-- MODIFY @computergroup1 AND @startdate/@enddate
-- BEWARE THAT @computergroup1 NAME CHARACTERS NUMBER CAN BE HOLD BY VARCHAR(N) VARIABLE
 
Use OperationsManagerDW
 
DECLARE @startdate    datetime
DECLARE @enddate    datetime
DECLARE @computergroup1    VARCHAR(100)
 
SET @startdate = '2017-09-01 00:00:00'
SET @enddate = '2017-09-30 00:00:00'
SET @computergroup1 = 'MyGroup'
 
 
SELECT 
av.AlertGuid
 
,apv.ParameterValue as SystemName
,av.AlertName
,adv.TicketId
,(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.RaisedDateTime)) as DownDateTime 
,(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),arsv.StateSetDateTime)) as RestoredDateTime
,adv.CustomField2 as OutageType 
,adv.CustomField3 as RootCause 
,Alert_ResolutionState = CASE
    WHEN arsv.ResolutionState = '255' THEN 'Closed'
    END
,adv.DBLastModifiedByUserId as UserID
FROM Alert.vAlert av
JOIN Alert.vAlertDetail adv on av.AlertGuid = adv.AlertGuid
JOIN Alert.vAlertResolutionState arsv on av.AlertGuid = arsv.AlertGuid
JOIN Alert.vAlertParameter apv on av.AlertGuid = apv.AlertGuid
 
 
-- JOIN ON TEMPORARY TABLE THAT RETRIEVE MAX OF StateSetDateTime (restoretime)
JOIN    (
        select av.AlertGuid 
        ,(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.RaisedDateTime)) as DownDateTime 
        ,MAX(arsv.StateSetDateTime) as restoretime
        from Alert.vAlert av
        JOIN Alert.vAlertDetail adv on av.AlertGuid = adv.AlertGuid
        JOIN Alert.vAlertResolutionState arsv on av.AlertGuid = arsv.AlertGuid
        JOIN Alert.vAlertParameter apv on av.AlertGuid = apv.AlertGuid
        GROUP BY av.AlertGuid,av.RaisedDateTime
        ) temp on temp.AlertGuid = av.AlertGuid
 
 
 
WHERE AlertName = 'Health Service Heartbeat Failure'
AND arsv.ResolutionState = '255'
AND (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.RaisedDateTime)) between @startdate and @enddate
 
 
 
and apv.ParameterValue IN (
SELECT vManagedEntity.DisplayName
FROM  vManagedEntity 
INNER JOIN vRelationship ON vManagedEntity.ManagedEntityRowId = vRelationship.TargetManagedEntityRowId 
INNER JOIN vManagedEntity AS ManagedEntity_1 ON vRelationship.SourceManagedEntityRowId = ManagedEntity_1.ManagedEntityRowId
    WHERE (ManagedEntity_1.DisplayName = @computergroup1)
)
 
 
AND arsv.StateSetDateTime = temp.restoretime
AND adv.TicketId is not null
 
GROUP BY apv.ParameterValue,adv.TicketId,av.AlertGuid,av.AlertName,av.RaisedDateTime,arsv.StateSetDateTime,adv.CustomField2,adv.CustomField3,/*adv.CustomField4,*/arsv.ResolutionState,adv.DBLastModifiedByUserId
ORDER BY apv.ParameterValue
 

 

Gestion de WSUS en Powershell - Partie 2

Dans l'article précédent nous avons vu comment nous connecter au serveur WSUS en Powershell, voyons maintenant ce que l'on peut récupérer informations.

1 - Etat de la configuration du serveur WSUS

Pour obtenir la configuration du serveur WSUS faites :

$Wsus.GetConfiguration()

Cette commande vous permet d'obtenir l'ensemble de la configuration du serveur.

Nous pouvons par exemple définir cette commande comme variable afin de pouvoir récupérer des informations de manière plus précise (car la commande retourne beaucoup d'informations).

Dans notre exemple nous allons récupérer les informations ci-dessous (pour information mon infrastructure possède un UpstreamServer) :

  • Le nom de l'UpstreamServer
  • Le port de connexion à l'UpstreamServer
  • Le serveur est il autorisé à synchroniser avec Windows Update
  • Le chemin d'accès au stockage des mise à jours
  • L'emplacement du fichier de log

J'ai variabilisé les requêtes car elles me servent plusieurs fois dans le script.

$Config = $Wsus.GetConfiguration()
$UpstreamServer = $Config.UpstreamWsusServerName
$UpstreamPort = $Config.UpstreamWsusServerPortNumber
$SyncFromMU = $Config.SyncFromMicrosoftUpdate
$StoragePath = $config.LocalContentCachePath
$LogPath = $Config.LogFilePath

$Config | Select-Object -Property UpstreamWsusServerName,UpstreamWsusServerPortNumber,SyncFromMicrosoftUpdate,LocalContentCachePath,LogFilePath

Si le serveur WSUS n'est pas le serveur en Amont (Upstream Server), donc en aval (Downstream Server) il est possible de connaitre ses paramètres via la commande :

$Wsus.GetSubscription()

Comme vous le voyez une information n'est pas retournée, ce n'est rien d'autre que les paramètre du serveur auquel vous êtes connecté, afin de connaitre ces informations rien de plus simple:

($Wsus.GetSubscription()).UpdateServer

Ou

$Subscription = $Wsus.GetSubscription()
$Subscription.UpdateServer


 

Pour obtenir des informations relatives aux mises à jour (Updates) comme : le nombre de mise à jour, combien sont approuvées, combien sont déclinées, combien sont nécessaires... utilisez la commande:

  $Wsus.GetStatus()

Après ces quelques petits exemples, vous me direz c'est bien mais pour l'instant ce n'est que de la collecte d'informations, comment puis je exploiter le serveurs alors? 

Dans la prochaine partie nous verrons comment interagir avec le serveur WSUS et lancer le nettoyage (Cleanup) du serveur.

Quest QMM et RUM : Définition des contrôleurs de domaine préférés

Bonjour à tous !

Aujourd'hui nous allons parler des produits QMM (Quest Migration Manager) et RUM (Resource Updating Manager).

Cet article s'adresse plus particulièrement aux personnes utilisant ce produit pour effectuer une migration de forêts AD contenant plusieurs sites Active Directory, donc plusieurs sites physiques différents.

En effet, pour effectuer des migrations utilisateurs/ordinateurs, les deux produits Quest font appel aux différents contrôleurs de domaine présents sur la forêt concernée.

Il peut arriver, pour des raisons pratiques, que vous vouliez migrer un utilisateur/ordinateur sur un contrôleur de domaine particulier.

Les paramètres de contrôleur de domaine préféré sont propres à chaque logiciel, ils sont donc à définir à la fois sur QMM et RUM suivant vos besoins.

Définition d'un contrôleur de domaine préféré pour QMM

1) Il faut d'abord déclarer une Domain Pair dans la console QMM avant de configurer le contrôleur de domaine préféré à utiliser.

2) Ouvrez les propriétés de l'Agent Manager en cliquant dessus.

3) Dans le menu de gauche, faites un clic-droit sur le nom de l'agent voulu et cliquez sur Properties.

4) Sélectionnez le domaine voulu et cliquez sur Edit.

5) Rentrez le contrôleur de domaine voulu dans les deux champs.

6) Le contrôleur de domaine préféré est configuré pour la migration des utilisateurs/groupes.

Définition d'un contrôleur de domaine préféré pour RUM

1) Il faut ouvrir l'éditeur de registre sur la machine où est installé RUM, puis aller à cet endroit de l'arborescence : HKLM\SYSTEM\CurrentControlSet\Services\QsRUMController

2) Une fois à cet endroit, il faut créer la clé config.

3) Une fois la clé crée, vous devez créer une entrée de type Chaîne (String).

La nomenclature du nom de la chaîne est importante.

Si le nom court (NetBIOS) du domaine voulu est DomainA pour le domaine DomainA.local par exemple, le nom de la chaîne doit être le suivant : DomaineAPreferredDC pour définir le contrôleur de domaine préféré sur le Domaine A.

4) La valeur de la chaîne correspond au FQDN du contrôleur de domaine voulu.

5) Il faut redémarrer la machine pour appliquer les modifications sur RUM.

Gestion de WSUS en Powershell - Partie 1

Gérer Windows Server Update Services c’est bien, mais on n’a pas toujours envie de se connecter à un ou plusieurs serveurs pour le faire. Et si on troquait l’interface graphique pour Powershell ?

I- Les prérequis

  • Depuis un poste client en Windows 7 :

Pour un poste en Windows 7 il faut installer le RSAT "Windows Server Update Services 3.0 SP2" disponible ici:

https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=5216

  • Depuis un serveur en Windows Server 2012 R2 :

Pour un serveur en Windows Server 2012 R2 il faut installer la fonctionnalité "Windows Server Update Services Tools"

II - Connexion au Serveur WSUS

Pour se connecter il va falloir déterminer 3 variables:

  • Le nom du serveur WSUS
  • L'utilisation ou non du SSL ($true ou $false)
  • Le port de connexion (8530, 8531, 80 ou 443)

Dans l'exemple que j'utilise je me connecterai sur le port 8530 sans SSL, d'où la présence du $false.

$WsusServer = "Mon-Server-WSUS"
$WsusPort = "8530"
[void][reflection.assembly]::loadwithpartialname("microsoft.updateservices.administration")
$Wsus = [microsoft.updateservices.administration.adminproxy]::getupdateserver($WsusServer,$false,$WsusPort)

Avec ces 4 lignes vous êtes connecté au serveur WSUS, pour le vérifier rien de plus simple, appelez $Wsus

III - Cmdlet disponibles

Pour déterminer les actions possibles sur le serveur regardons les cmdlet disponibles, pour cela utilisons : 

$Wsus | gm

Comme vous pouvez le voir nous avons un grand nombre d'actions possibles.

Dans la prochaine partie nous verrons les informations que nous pouvons récolter avec quelques lignes de commandes.

Active Directory : NETDOM et les contrôleurs de domaine en français

Bonjour à tous !

Aujourd'hui, nous allons parler de la commande Netdom trust (nous allons donner plus de détails sur cette commande dans un prochain article).

Quand vous êtes dans le cadre d'une migration de forêt/domaine Active Directory, il est probable que vous vouliez autoriser l'utilisation des SidHistory afin de préserver les accès aux ressources du domaine historique pour les postes/utilisateurs migrés.

Pour se faire, nous utilisons deux commandes (depuis un contrôleur de la nouvelle foret) :

  • netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine:yes/no
  •  netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /EnableSidHistory:yes/no

Mais que se passe t'il si vous entrez cette commande sur un contrôleur de domaine en langue française ?

Nous entrons donc la commande suivante afin d'avoir le statut de la mise en quarantaine des SID : netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine

Nous voulons maintenant effectuer une action en désactivant la mise en quarantaine des SID : netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine:no

Bizarre, nous obtenons le même message que pour la commande précédente ...

Après vérification, la commande n'a pas désactivé le filtrage.

En revanche, si vous entrez la version suivante de la commande, vous obtiendrez un résultat fort différent ! 

netdom trust DomaineHistorique /D:NouveauDomaine /UO:Utilisateur_Nouveau_Domaine /PO:* /Quarantine:non

Et voilà ! La commande marche enfin ! Elle n'a été traduite que pour un seul paramètre.

Il est à noter qu'il faut faire exactement la même chose pour le paramètre /EnableSidHistory.

Vous êtes désormais averti, ce bug est encore présent même sous Windows Server 2012 R2.

Remplacer tous les mots de passe en claire dans un dossier donné en powershell

Bien souvent, en entreprise on se retrouve avec des dossiers contenant des fichiers *.ini d'installation ou autres avec des mots de passe stockés en claire. Prenons, le cas des installations SQL , le DBA enregistre les mots de passe dans un fichier de paramètre et ne pense pas à le supprimer. Les mots de passe en claire posent un problème de sécurité au SI. Le script en powershell ci-dessous permettrait de remplacer tous les mots de passes en claire par des étoiles (**********). 

#############################################
#Author: KARUPPANNAN Seevadassen            #
#Date: 27/03/2017                           #
#############################################

$networkPath = "\\chemin\dossier\"

$iniS = Get-ChildItem -Path $networkPath -Filter *.ini -Recurse

foreach ($file in $iniS) {

$fileName = $file.Name
$filePath = $file.FullName

Write-Host "File name: " $fileName -ForegroundColor yellow
Write-Host "Full path: " $filePath -ForegroundColor yellow

$array = $filePath.split("\")
$server = $array[8]

Write-Host "Server: " $server

$password = Get-Content $filePath | Where-Object { $_.Contains("SAPWD") -or $_.Contains("SQLSVCPASSWORD") -or $_.Contains("AGTSVCPASSWORD") -or $_.Contains("FTSVCPASSWORD") -or $_.Contains("ISSVCPASSWORD") -or $_.Contains("ASSVCPASSWORD") -or $_.Contains("RSSVCPASSWORD") -or $_.Contains("FARMPASSWORD")}

Write-Host $password
Write-Host $password.GetType()

foreach ($line in $password){

      $row = $server + ";" + $line
      Write-Host "row value: " $row -ForegroundColor Green

      Write-Host "line: " $line
      $param1,$param2 = $line.split('=') 
      Write-Host "partie1: " $param1


      $replacetxt =  $param1 + '=' + '"' + "********" + '"' 


      Write-Host "replace with " $replacetxt

try {

            (Get-Content $filePath) -replace $line,$replacetxt | Set-Content $filePath

            Write-Host "SUCCESS:Password has been replaced!" -ForegroundColor Green

      }catch{

            Write-Host "ERROR:Password has NOT been replaced!" -ForegroundColor red
            $ErrorMessage = $_.Exception.Message
            Write-Host $ErrorMessage
}

}

Write-Host "---"
}

 

Dans les fichiers *.ini, le script powershell va chercher toutes les lignes qui contiennent les mots clés "SAPWD","SQLSVCPASSWORD","AGTSVCPASSWORD","FTSVCPASSWORD"... et replacer par la suite les mots de passe par des étoiles.

 

Windows 7 : RSAT WSUS

Par défaut dans les Outils d'administration des serveurs distant (Remote Server Administration Tools = RSAT) la console WSUS (Windows Server Update Services) n'est pas présente.

Il est possible d'installer la console en ajoutant la KB972455 pour Windows Server Update Services 3.0 SP2 disponible ici:

https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=5216

Une fois l'installation finie vous disposez de la console WSUS dans vos RSAT.