Dans l’exemple suivant, Le script transfert les extracts scom du précedent article (https://blog.piservices.fr/post/2018/09/27/Script-Powershell-Extract-SCOM-to-CSV) vers un partage unix en utilisant les commandes du module Posh SSH.

Pour plus d’information sur le module Posh-SSH:

https://github.com/darkoperator/Posh-SSH

https://www.it-connect.fr/posh-ssh-connexion-ssh-depuis-powershell-sous-windows/

### TRANSFER CSV FILES THROUGH SFTP TO UNIX SHARE ###

# Requirement: POSH SSH Powershell Module (https://github.com/darkoperator/Posh-SSH)


param(
$UnixServ = ("MyLinuxSrv1","MyLinuxSrv2"),
$FilePath="D:\*.csv",
$SftpPath = "/home/myself/scomextract",
$FileToKeepCount = 2
)

$ScriptName = "SendCSVBySftp.ps1"


$SshModuleFile = "D:\Posh-SSH-master.zip"
$PSModulePath = "$($env:WINDIR)\system32\WindowsPowerShell\v1.0\Modules"



#FUNCTIONS

#Check for the existence of an event source with script name in operation manager eventlog to log some events 
         Function NewEventSource { 
         if(!(Test-Path "HKLM:\SYSTEM\CurrentControlSet\services\eventlog\Operations Manager\$ScriptName")) 
         { 
         New-EventLog -LogName "Operations Manager" -Source $ScriptName 
         }
         } 

#END FUNCTIONS

# LOG THE EXECUTION OF SCRIPT
$Message = "Execution of $ScriptName script"
write-host $Message
NewEventSource
Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1000 -EntryType Information -Message "$Message"



# Get the credentials from the previously secured passfile.txt
$CredPath = "D:\passfile.txt"
if (!(Test-Path $CredPath))
    {
    $message = "Credential secured file is not present - Unable to authenticate"
    Write-Host -F Red $message
    NewEventSource
    Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1001 -EntryType Warning -Message $message
    }


# Import the credential file
$Credential = Import-Clixml -Path $CredPath



# Check that $PSModulePath path exist
if (!(Test-Path $PSModulePath))
    {
    $message = "$PSModulePath path doesn't exist"
    Write-Host -F Red $message
    NewEventSource
    Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1002 -EntryType Warning -Message $message
    exit 1
    }


# Check if module has already been installed, and if not, install it as $PSModulePath+"\Posh-SSH"
If (!(Test-Path ($PSModulePath+"\Posh-SSH")))
            
            {


            #Unzip the SSH Powershell Module to Standard Module Path

            $shell_app=new-object -com shell.application
            $zip_file = $shell_app.namespace($SshModuleFile)
            Write-Host "Uncompressing the Zip file to $($PSModulePath)" -ForegroundColor Cyan
            $destination = $shell_app.namespace($PSModulePath)
            $destination.Copyhere($zip_file.items(), 0x10)


            # Rename the SSH Module Folder
            Write-Host "Renaming folder" -ForegroundColor Cyan
            Rename-Item -Path ($PSModulePath+"\Posh-SSH-master") -NewName "Posh-SSH" -Force

            Write-Host "Module has been installed" -ForegroundColor Green

            }


# Import of SSH Module
Write-Host -F Cyan "SSH Powershell Module already installed"
Write-Host -F Cyan "Import of SSH Powershell Module..."
Import-Module -Name posh-ssh


$UnixServ | foreach {

    # Establish the SFTP connection
    $SftpSession = New-SFTPSession -ComputerName $_ -Credential $Credential -AcceptKey



    # Check that $SftpPath exist
    if (!(Test-SFTPPath -SessionId $SftpSession.SessionId -Path "/$_$SftpPath"))
        {
        $message = "Unable to find `"/$_$SftpPath`" path"
        Write-Host -F Red $message
        NewEventSource
        Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1003 -EntryType Warning -Message $message
        exit 1
        }


        # Upload each file to the SFTP path
        try
        {
        Get-ChildItem -Path $FilePath | foreach {Set-SFTPFile -SessionId $SftpSession.SessionId -LocalFile $_ -RemotePath $SftpPath -Overwrite}
        }
        catch
        {
        $message = "Error during Sftp transfer To `"/$_$SftpPath`" path"
        Write-Host $message
        NewEventSource
        Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1004 -EntryType Warning -Message $message
        exit 1
        }


# Check that files are effectively present on sftp path
Get-ChildItem -Path $FilePath | foreach {

If (!(Test-SFTPPath -SessionId $SftpSession.SessionId -Path "$SftpPath/$($_.Name)"))
    {
    $message = "KO - The $($_.Name) file has not been copied on $($SftpSession.Host)$SftpPath"
    Write-Host -F Red $message
    NewEventSource
    Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1005 -EntryType Warning -Message $message
    exit 1
    }
    Else
    {
    $message = "OK - The $($_.Name) file has well been copied on $($SftpSession.Host)$SftpPath"
    Write-Host -F Green $message
    NewEventSource
    Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1006 -EntryType Information -Message $message
    }

}

}


#Delete older remote files
Get-SFTPSession | foreach {
$FileToDelete = Get-SFTPChildItem -SessionId ($_.SessionId) -Path $SftpPath | Where-Object {$_.fullname -like "*.csv"} | sort lastwritetime | select -First $FileToKeepCount
$FileToDelete
}




# Remove SftpSessions
Get-SFTPSession | foreach {Remove-SFTPSession -SessionId ($_.SessionId)}

Le script suivant extrait les agents, management servers et gateways vers un fichier CSV en ne conservant que le plus recent.

Decommentez la section <# + $datetime#> pour ajouter au nom du fichier, la date de création.

#############################################################
### EXTRACT OF ALL AGENTS MONITORED BY SCOM TO A CSV FILE ###
#############################################################



Param(
[Parameter(Mandatory=$true)]$MS,
[Parameter(Mandatory=$true)]$OutPutPath
)

$ScriptName = "ExtractAssetFromSCOM.ps1"

#FUNCTIONS

#Check for the existence of an event source with script name in operation manager eventlog to log some events 
         Function NewEventSource { 
         if(!(Test-Path "HKLM:\SYSTEM\CurrentControlSet\services\eventlog\Operations Manager\$ScriptName")) 
         { 
         New-EventLog -LogName "Operations Manager" -Source $ScriptName 
         }
         } 

#END FUNCTIONS

# LOG THE EXECUTION OF SCRIPT
$Message = "Execution of $ScriptName script"
write-host $Message
NewEventSource
Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1000 -EntryType Information -Message "$Message"


#Import of SCOM PS Module
try
{
Import-Module -Name OperationsManager -ErrorAction stop
}
catch
{
$Message = "Error during import of SCOM PS Module"
write-host -ForegroundColor red $Message
NewEventSource
Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1001 -EntryType Warning -Message "$Message"
exit 1
}

#Connection to $MS
try
{
$ScomCon = New-SCOMManagementGroupConnection -ComputerName $MS -PassThru
}
catch
{
$Message = "Error during connection to $MS - Check the credentials used"
write-host -ForegroundColor red $Message
NewEventSource
Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1002 -EntryType Warning -Message "$Message"
exit 1
}


$MGroup = $ScomCon.ManagementGroupName

#AGENT INFO SECTION

        #$Agents - ALL AGENTS + ALL MS AND GW, SORTED BY DISPLAYNAME
        try
        {
        $Agents = Get-SCOMAgent | select DisplayName -ExpandProperty DisplayName 
        $Agents += Get-SCOMManagementServer | select DisplayName -ExpandProperty DisplayName
        $Agents = $Agents | Sort-Object -Property DisplayName
        }
        catch
        {
        $Message = "Error during retrieve of agents list"
        write-host -ForegroundColor red $Message
        NewEventSource
        Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1003 -EntryType Warning -Message "$Message"
        exit 1
        }



                
   # Initiate the table    
   $export_array = @();

   # Fill of table
   foreach ($Ag in $Agents)
   {
   $export_array += @($Ag+','+$MGroup);
   }


# Naming of CSV file
$datetime = Get-Date -Format "yyyy.MM.dd_HH-mm-ss";
$file_name = "Extract_SCOM_$MGroup`_"<# + $datetime#> + ".csv"; # Uncoment "<# + $datetime#>" to add creation date of file
$file_path = "$OutPutPath\" + $file_name;


# Fill of CSV File
foreach($ColItem in $export_array)  
{  
  $csv_string = "";
  foreach($item in $ColItem)
  {
    $csv_string = $csv_string + $item ;
  }
  [array]$content += $csv_string
}

Set-Content $file_path $content


# Check of File Creation
if (Test-Path $file_path)
{
  $Message = "Creation of CSV file`"$file_path`" OK!"
  write-host -ForegroundColor Green $Message
  NewEventSource
  Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1004 -EntryType Information -Message "$Message"
  
}
else
{
  $Message = "Creation of CSV file KO!"
  write-host -ForegroundColor Red $Message
  NewEventSource
  Write-EventLog -LogName "operations manager" -Source $ScriptName -EventId 1005 -EntryType Warning -Message "$Message"
  exit 1
}

Write-Host $file_name
Write-Host $MGroup


# Deletion of oldest files (keep only the newest)

Write-Host "...Deletion of oldest files..."
if ($(Get-ChildItem "$OutPutPath\*SCOM_$MGroup*").count -gt 1)
    {
    $Newest = Get-ChildItem "$OutPutPath\*SCOM_$MGroup*" | sort creationtime | select -last 1
    Get-ChildItem "$OutPutPath\*SCOM_$MGroup*" | Where-Object {$_.Name -ne $Newest.Name} | Remove-Item
    }
    

Bonjour à tous,

Aujourd'hui nous abordons la partie 2 de notre série sur la migration du dossier SYSVOL du mécanisme FRS vers DFS-R, elle sera consacrée au déroulement global de celle-ci.

Etats de migration

Etats de migration globaux et locaux

Il existe deux types d'états de migration :

• Global : Les commandes pour initier les étapes de migration vont agir sur le PDC. Une fois que l'état de migration a changé sur le PDC, il est défini au niveau du domaine Active Directory, d'oû sa portée globale.
• Local: Une fois que l'état de migration a été défini sur le PDC, chaque contrôleur de domaine annexe va évaluer son propre état de migration par rapport à celui du domaine et va effectuer les opérations demandées si les deux ne correspondent pas. D'ou un état de migration local propre à chaque contrôleur de domaine.

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Au niveau de chaque controleur de domaine, il existe 6 états locaux qui sont les suivants :

Schématiquement, nous pouvons résumer la migration (et un retour arrière) comme ceci :

Remarques importantes

• Un niveau fonctionnel de forêt/domaine AD 2008 minimum est nécéssaire pour démarrer la migration.
• Une copie du dossier original SYSVOL, appelée SYSVOL_DFSR et située au même endroit que le dossier SYSVOL orinigal, est utilisée en parallèle par DFS-R pour la réplication des données.
• La commande dfsrmig est utilisée pour configurer les états de migration et est à utiliser de préférence sur le PDC du domaine conerné, ou tout du moins sur n'importe quel contrôleur de domaine accéssible en écriture (hors RODC donc).
• Le retour arrière n'est possible que jusqu'à l'état 2. Pas de retour arrière possible une fois le domaine en état 3.
• Il faut vérifier manuellement l'état de réplication du dossier SYSVOL à chaque étape. Il n'y a pas de vérification automatique de l'intégrité du dossier SYSVOL lors de l'utilisation de la commande dfsrmig.
• Il n'est pas possible de renommer un contrôleur de domaine pendant toute la durée de la migration.
• Toute modification de GPOs, ou d'ajout/suppression de contrôleur de domaine durant la durée de la migration est fortement déconseillée, mais reste toutefois possible.
• Un contrôleur de domaine peut être éteint et allumé de nouveau pendant la migration.
• Les états de transitions sont plus longs pour les RODCs (c'est le PDC qui fait les opérations pour eux) et les sites distants.

Commandes utiles

• dfsrmig /GetGlobalState : Indique l'état de migration du dossier SYSVOL au niveau du domaine AD
• dfsrmig /SetGlobalState Numero_etat_de_migration (0,1,2,3) : Configure l'état de migration du dossier SYSVOL au niveau du domaine AD
• dfsrmig /GetMigrationState : Indique l'état de migration du dossier SYSVOL pour tous les contrôleurs de domaine du domaine AD
• repadmin /syncall /AeD : Force la syncronisation de tous les contrôleurs de domaine AD

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la première étape, Prepared.

Bonjour à tous,

Aujourd'hui nous commençons une série de billets consacrée à la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R.

Historique

FRS (File Replicating System) est un mécanisme de réplication de fichiers introduit avec Windows 2000 et à été utilisé au sein d'Active Directory pour la réplication du dossier SYSVOL.

Avec l'arrivée de Windows Server 2008, Microsoft a introduit une nouvelle technologie appellée DFS (Distributed File System). Cette technologie se décline en deux composants : DFS-N (qui gère les espaces de noms de dossiers partagés) et DFS-R (qui gère la réplication entre des dossiers).
Microsoft a rendu possible l'utilisation de DFS-R pour la réplication du dossier SYSVOL depuis Windows Server 2008 (et son niveau fonctionnel de forêt/domaine correspondant).

A partir de Windows Server 2008 R2, Microsoft ne permet plus l'utilisation de la technologie FRS pour la réplication de dossiers mais pour des raisons de compatibilité laisse cette possiblité pour le dossier SYSVOL jusqu'à Windows Server 2012 R2 (et son niveau fonctionnel de forêt/domaine correspondant).

Pourquoi migrer ?

Le mécanisme FRS n'est plus supporté par aucun contrôleur de domaine à partir de Windows Server 2016.

Plus précisemment, même si vous voulez ajouter un contrôleur de domaine sous OS Windows Server 2016 et garder un niveau fonctionnel de forêt/domaine Windows Server 2012 R2, ce n'est pas possible car Microsoft à tout simplement retiré les binaires FRS de l'OS ! (ce n'était pas le cas jusqu'à la RS3).

Même si vous avez effectué une montée du niveau fonctionnel d'une forêt AD, la migration de FRS vers DFS-R n'est pas éffectuée automatiquement.

DFS-R est le mécanisme de réplication utilisé par défaut pour le dossier SYSVOL depuis le niveau fonctionnel de forêt/domaine AD 2008 pour toute création d'une nouvelle forêt AD avec un niveau fonctionnel de forêt/domaine 2008. Si vous êtes dans ce cas, alors il n'y a pas de migration à prévoir.

En revanche, si vous avez hérité d'une forêt AD historique remontant à Windows Server 2003 et que vous n'avez éffectué uniquement que des montées de niveau fonctionnel de forêt/domaine AD sans vous préoccuper du SYSVOL, il y a de fortes chances pour que FRS soit toujours utilisé pour sa réplication.

Comment vérifier si FRS est toujours utilisé ?

Il faut passer par la console ADSIEdit.

Connectez-vous au Default Naming Context (Contexte de nommage par défaut).

Dans l'aborescence, allez dans CN=votredomaine,DC=local -> CN=System -> CN=DFSR-GlobalSettings. Ouvrez les propriétés de CN=DFSR-GlobalSettings.

Cherchez la propriété msDFSR-Flags et notez la valeur présente.

Si la valeur est nulle, alors c'est FRS qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 48, alors c'est DFS-R qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 0, 16 ou 32 alors c'est que la migration du mécanisme de réplication est en cours (0 correspond à l'état Start, 16 correspond à l'état Prepared, 32 correspond à l'état Redirected et 48 correspond à l'état Eliminated).

Dans le prochain billet, nous aborderons la procédure de migration du dossier SYSVOL du mécanisme FRS vers DFS-R.

Contexte

Afin de purger une table, deux solution sont possibles :

“TRUNCATE table Table_a_vider” ou “DELETE from Table_a_vider”

La principale différence entre ces deux commandes est la suivante :

• TRUNCATE est une commande DDL, cette commande est beaucoup plus rapide, mais son action est irrémédiable,
• DELETE est une commande DML, sa durée d’exécution dépends du volume de données à traiter.

Ces deux commandes ont malgré tout pour point commun de nécessiter un lock exclusif sur les données à supprimer. Si ce lock n’est pas obtenu, la commande vas continuer de s’exécuter jusqu’à l’obtenir.

Afin de ne pas attendre, il faut détecter la session provoquant le blocage et la stopper si possible.

Résolution

La commande suivante permet de lister toutes les transactions bloquées :

USE Master
GO
SELECT *
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;
GO

La commande sp_who2 liste toute les sessions avec leur numéro de SPID, il suffit de retrouver la session remontée par la commande précédente puis de se référer à la colonne “BlkBy” afin d’identifier le process qui la bloque.

La commande suivante permet d’afficher la commande exécutée par le SPID indiqué, cela permet d’évaluer le risque avant de stopper la session à l’aide de la commande “kill”

dbcc inputbuffer(SPID)

Contexte

Ce post explique comment créer un job qui permet de vérifier automatiquement la cohérence d’une base de donnée.

Résolution

Depuis SQL Server Management Studio, depuis le dossier “Management”, créer un nouveau plan de maintenance :

Ajouter la tâche de vérification de l’intégrité de la base depuis la ToolBox :

Indiquer les bases à vérifier :

Eventuellement, indiquer l’action à réaliser en cas de succès ou d’échec du job :

Contexte

Ce post explique comment restaurer une base de donnée sous un différent nom/emplacement

Résolution

Récupérer le nom logique de la base :

RESTORE FILELISTONLY FROM DISK='c:\backup.bak'

Restaurer la base sous un autre nom logique / emplacement :

RESTORE DATABASE NouveauNomLogique FROM DISK='c:\backup.bak'
WITH 
   MOVE 'NomLogiqueduMDF' TO 'c:\NouveauNomLogiqueduMDF.mdf',
   MOVE 'NomLogiqueduLDF' TO 'c:\NouveauNomLogiqueduLDF_log.ldf'

Bonjour à tous,

Avec Windows 10, Microsoft a introduit un nouveau type de mises à jour appellées Servicing Stack Updates.

Que concernent-elles ?

Ces mises à jour concernent uniquement le composant Servicing Stack de Windows.

Le Servicing Stack est responsable de deux choses principalement au sein de l'OS Windows :

• L'installation de mises à jour
• L'installation de rôles ou de fonctionnalités supplémentaires via la couche CBS (qui inclue elle même les composants SFC et DISM notamment)

Comment sont-elles distribuées ?

Les mises à jour SSU ne sont pas incluses dans les mises à jour mensuelles cumulatives de Microsoft.

Elles constituent des mises à jour entièrement indépendantes et doivent donc être approuvées séparement dans WSUS afin que celles-ci puissent être déployées sur les postes concernés.

Elles seront cependant déployées automatiquement sur les postes ayant pour source Microsoft Update et non WSUS.

Attention, chaque SSU (tout comme les patchs cumulatifs mensuels), sont spécifiques à chaque version (Servicing Branch) de Windows 10 (1607, 1703, ...).

Sont-elles obligatoires ?

La réponse est oui.

Les SSU sont un prérequis pour l'installation de certaines mises à jour mensuelles cumulatives.

Le cycle des SSU est différent de celui des mises à jour mensuelles cumulatives, donc il y a des mises à jour mensuelles cumulatives sans SSU correspondante. Si une SSU est un pré-requis à une MAJ mensuelle cumulative spécificfique, elle le sera également pour les MAJ mensuelles cumulatives suivantes.

Existe t'il une liste des SSU ?

Sont-elles désinstallables ?

Au contraire des autres mises à jour Microsoft, les SSU concernant un composant clé de Windows et uniquement lui seul (d'ou leur petite taille contrairement à celle des MAJ cumulatives mensuelles), ces mises à jour ne sont pas désinstallables.

Seule la restauration système peut être envisagée si vous devez vraiment faire marche arrière.

Bonjour à tous !

Aujourd'hui voici un billet pour les personnes rencontrant des problèmes de coupures intempestives sur des lecteurs réseau.

Contexte :

Des utilisateurs travaillant sur des lecteurs réseau vous rapportent des problèmes d'accès intempestifs à leurs fichiers, avec des coupures ou des lecteurs marqués comme déconnectés dans le poste de travail.
Ces coupures peuvent intervenir à n'importe quel moment de la journée et ne suivent pas des intervalles précis.

Cependant les serveurs hébergeant les partages concernés par les coupures semblent être toujours les mêmes, tout comme les postes de travail.

Vous pouvez remarquer que les plantages surviennent aussi lorsque les fichiers sont utilisés sur de longues periodes (applicatif sur un lecteur réseau par exemple).

Solution :

Depuis Windows Server 2012 R2 ainsi que Windows 8, Microsoft a introduit une nouveauté dans le traitement des stratégies de groupe.

Le traitement des paramètres de préférences de stratégies de groupe (les fameuses Group Policy Preferences), et plus particulèrement celles concernant les lecteurs réseau se passe désormais en arrière-plan (background processing) et non plus uniquement à l'ouverture de la session d'un utilisateur (foreground processing).

En conséquence, quand vos lecteurs réseau sont mappés avec l'option Replace et non l'option Update, chaque rafraîchissement de la stratégie de groupe concernée entrainera une suppression du lecteur réseau, puis sa re-création provoquant ainsi une coupure temporaire.

C'est donc une nouvelle Best Practice à adopter, l'option Replace ne doit être utilisée que lorsque vous avez besoin d'écraser un paramètre pour le remplacer par un différent (je pense notemment à des mappages d'imprimantes lors d'un changement d'imprimante), l'option Update doit désormais être préférée pour tous les éléments ne devant pas être écrasés mais simplement mis à jour.

A bientôt,

Bonjour à tous !

Aujourd'hui voici un court billet pour les personnes travaillant sous Windows Server Core.

Contexte :

Vous travaillez sur Windows Server Core, donc sans aucune GUI installée.

Vous êtes connecté au serveur à travers une connexion RDP.

Pour une raison X ou Y, au cours de votre session de travail, vous fermez malencontreusement votre invite de commande ou console PowerShell et vous n'avez plus aucun moyen de l'ouvrir !

Problématique :

Habituellement, le seul moyen de relancer une invite de commande ou une console Powershell est de passer par le Gestionnaire des tâches, qui peut s'ouvrir à l'aide la commande Ctrl+Alt+Suppr.

Si vous accéder au serveur en utilisant une connection à distance avec un rebond, la commande Ctrl+Alt+Suppr n'est pas prise en compte au sein du dernier bureau à distance ouvert, donc vous ne pouvez pas ouvrir le Gestionnaire des tâches via le raccourci habituel.

Solution :

Il existe cepandant un raccourci afin d'ouvrir le Gestionnaire des tâches, qui est Ctrl+Shift+Escape

Ensuite, il suffit de cliquer sur le menu File puis sur Run New Task afin de relancer au choix l'exécutable correspondant à la console Invite de commande ou à la console Powershell.

Bonus :

Voici la liste des consoles toujours accéssibles sous Windows Server Core et celles qui ne le sont plus :

 A bientôt,