Exécuter Excel sur un poste Distant.

Quel est l'interêt ?

En dehors du fait qu'installer Excel sur un serveur n'est pas forcément une bonne pratique, dans mon cas cela me permet d'automatiser à 100% mes scripts Powershell, ces derniers fournissent des rapports détaillés à mes interlocuteurs, sans que je n'ai besoin de faire quelques modifications que ce soit (contrairement à un CSV).
Ainsi les scripts tournent de nuit et permettent à chacun de trouver son rapport le matin en arrivant, et ce même pendant mes vacances.

Comment ça marche

Pour exécuter Excel sur un poste distant via Powershell il faudra cumuler 2 paramètres.

1. Activer CredSSP pour la délégation des identifiants.
2. Autoriser le compte d'exécution à se servir de l'application Excel à Distance.

Voyons comment réaliser cela.

1- Activer CredSSP

J'ai déjà traité le sujet ICI.

2- Gestion Excel Distant

Attention la modification que nous allons réaliser n'est pas sans conséquence, comme nous pourrons le voir après, l'application Excel devient vraiment limitée pour tout autre utilisateur que celui qui sera déclaré.

Pour pouvoir autoriser le compte d'exécution à se servir de l'application Excel à distance, nous aurons besoin de la MMC.

Sur la machine qui traitera le fichier Excel :

• Ouvrir la MMC > Ajouter ou supprimer des composants logiciels enfichables > Services de composants.

• Développer Services de composants > Ordinateurs > Poste de travail > Configuration DCOM

• Sur "Microsoft Excel Application" faites clic droit "propriétés", dans la fenêtre sélectionnez l'onglet "Identité"

• Cochez la case "Cet utilisateur" puis faites "parcourir", sélectionnez "Tout l'annuaire" et enfin recherchez le compte d'exécution du script.

• Entrez le mot de passe de votre compte d'exécution et faites "Appliquer".

Maintenant que le paramètre est fixé seul le compte définit est "autorisé" à se servir de l'application Microsoft Excel, l'expérience pour tout autre utilisateur est vraiment dégradé (pas d'impression, de sauvegarde, message d'erreur...); par conséquent si vous souhaitez pouvoir continuer à utiliser Excel, je vous invite à repasser sur "L'utilisateur exécutant" et n'activer la fonction que lors de l'exécution du script (pour ma part je ne l'active sur mon poste que la nuit).

Exemple de message d'erreur.

Annexe

En annexe un petit article sur la gestion d'Excel en Powershell :

https://blog.piservices.fr/post/2013/03/27/Powershell-Creation-de28099objets-personnalises

Dans le cadre d’un portage de règle de supervision, les trois scripts ci-dessous ont été crées pour remonter l’état de:

- Un Availability Group

- Un Availability Replica

- Un Database Replica

En pratique ils utilisent a peu près la même requête SQL. Ils contiennent des éléments propre a l’api scom mais peuvent bien sur être adapté pour être utilisé indépendamment.

Ci-dessous les 3 scripts et l’exemple du code du premier, Check_SQL_AO_AvailabilityGroupStatus_Query_Version.ps1.

Une demande m’a été faite récemment pour la détection de l’occurrence de deux events distinct a la même seconde, ce cas particulier traduisant un problème de sécurité spécifique.

Indépendamment de l’objectif final, il s’agit d’un cas intéressant auquel le script ci-dessous a répondu. Il contient des éléments propre a l’api scom mais peux bien sur être adapté pour être utilisé indépendamment.

CredSSP qu'est ce que c'est ?

CredSSP : Credential Security Service Provider.

A quoi cela sert-il ?

A déléguer des identifiants pour une session distante, plus précisément, CredSSP vous permet de fournir une authentification de bout en bout au travers de plusieurs sessions distantes.

Exemple :

Depuis un Serveur A un script Powershell ouvre une session distante sur un Serveur B, ce dernier traite ses instructions puis ouvre une session distante pour requêter un Serveur C et y déposer ses résultats sur un partage.

Lors de l'ouverture de la session distante entre A et B Windows utilise les identifiants fournis, mais lors de l'ouverture de la session distante depuis B vers C, Windows considère qu'il s'agit d'une usurpation Kerberos (car par défaut WinRm n'autorise pas la délégation des identifiants).

Afin de palier  cela que ce soit pour un "Invoke-Command" ou un "New-PSSession" vous devrez ajouter "-Authentication CredSSP"; cet ajout vous permettra de déléguer les identifiants pour la seconde session distante.

Mise en oeuvre :

Et non, on ne peut pas utiliser l'option CredSSP sans prérequis, voici ceux à mettre en place.

Sur le Serveur A on va activer CredSSP "Client" via la commande suivante :

Enable-WSManCredSSP -Role Client -DelegateComputer ServerB.mondomaine.com -Force

On peut vérifier que cela à bien fonctionné à l'aide de la commande suivante :

Get-WSManCredSSP

Puis sur le Server B on va activer CredSSP "Server" via la commande suivante :

Enable-WSManCredSSP -Role Server -Force

vérifions.

Et voilà nous devrions donc pouvoir exécuter la commande initiale depuis le serveur A, vérifions cela sans oublier d'ajouter "-Authentication CredSSP".

Enter-PSSession -ComputerName lab01-wsus1.LAB.ORG -Credential Lab\Adminmad -Authentication Credssp

Jusque la tout fonctionne, essayons donc maintenant de requêter vers le serveur C.

Invoke-Command -ComputerName Lab01-wsus2.lab.org -ScriptBlock {Get-WindowsFeature | Where-Object {$_.Name -like "UpdateServices"}}

C'est bien fonctionnel, bien entendu comme ce changement est lié à la sécurité, il est préconisé de désactiver cette option après usage.

On peut utiliser les commandes :

Disable-WSManCredSSP –Role Client # Sur le serveur A
Disable-WSManCredSSP –Role Server # Sur le serveur B

Ou directement depuis le serveur A :

Invoke-Command –ComputerName ServerB –ScriptBlock { Disable-WSManCredSSP –Role Server }
Disable-WSManCredSSP –Role Client

Annexes :

Vous pouvez aussi le faire sur plusieurs Serveurs : 

Enable-WSManCredSSP -Role "Client" -DelegateComputer "ServerB.mondomaine.com", "ServerC.mondomaine.com", "ServerD.mondomaine.com" -Force

Ou sur toutes les machines du domaine :

Enable-WSManCredSSP -Role "Client" -DelegateComputer "*.mondomaine.com" -Force

 Pour plus d'informations:

https://docs.microsoft.com/en-us/powershell/module/microsoft.wsman.management/enable-wsmancredssp?view=powershell-6 

https://msdn.microsoft.com/en-us/library/windows/desktop/bb931352(v=vs.85).aspx

Problème

Lors de l'utilisation d'un script qui génère plusieurs requêtes depuis plusieurs serveurs en simultané afin d'alimenter une banque de données, je me suis heurté au message d'erreur suivant :

get-adcomputer : A connection to the directory on which to process the request was unavailable. This is likely a 
transient condition.
At C:\temp\Fusion.ps1:97 char:1
+ get-adcomputer -Filter {DNSHostName -eq $FullName} -Properties OperatingSystem | Select-Object -Property N ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-ADComputer], ADException
    + FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADComputer

Explication

Cette erreur est liée aux valeurs par défaut du service "Active Directory Web Services" définies dans le fichier de configuration sur les DC sous : 

C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.config

En effet si vous éditez le fichier de configuration vous pourrez voir que par défaut le maximum de connexions LDAP par utilisateur est de 5.

<add key="MaxConnectionsPerUser" value="5" />

Ce qui signifie que je ne peux exécuter plus de 5 connexions en simultanée via Active Directory Web Services avec les même identifiants.

Il est possible de modifier cette valeur, mais cette action n'est pas recommandée car elle peut avoir un impact sur les performances de l'AD.

Si toutefois vous souhaitez la modifier, certaines précautions sont à prendre; il est clairement précisé dans le fichier de configuration que la valeur de "MaxConnectionsPerUser" ne peut pas être plus grande que la valeur de "MaxPoolConnections", il faudra donc aussi prendre en compte la valeur suivante :

<add key="MaxPoolConnections" value="10" />

Cette dernière spécifie que le nombre maximal de connexions LDAP, pour chaque instance de service d'annuaire prise en charge par le service ADWS s'exécutant sur un serveur.

Il peut être aussi intéressant de regarder la valeur de la clé ci-dessous : 

<add key="MaxPercentageReservedConnections" value="50" />

Celle-ci permet, de spécifier le pourcentage maximal de connexions LDAP pouvant être utilisées pour effectuer des requêtes pour chaque instance de service d'annuaire prise en charge par le service ADWS sur un serveur.

Attention :

Même s'il est possible de modifier les paramètres ci-dessus, Microsoft ne le préconise pas (cf: note ci-dessous) :

Plusieurs paramètres de configuration du service ADWS affectent la limitation de la bande passante sur un serveur Windows Server 2008 R2 sur lequel le service ADWS est en cours d'exécution.
Nous recommandons aux administrateurs de modifier les valeurs par défaut des seuls paramètres suivants:
MaxConcurrentCalls, MaxConcurrentSessions, MaxReceivedMessageSize et MaxStringContentLength.

Compléments d'informations:

https://technet.microsoft.com/en-us/library/373e68b3-abfc-4da4-ae89-72a15cfc7543

Le script ci-dessous montre comment facilement sortir de petit rapport en ligne de commande de l’état d’un monitor pour tout les agents.

Dans cet exemple on affiche l’état du rollup monitor de l’espace disque (FreeSpaceMonitorRollup) et l’information de maintenance mode.

1- Décliner des KB

Voici comment décliner toutes les KB de sécurité remplacées (Superseded).

# Decline Action
$KBState = $Wsus.GetStatus()
$DeclinedBefore = $KBState.DeclinedUpdateCount
$DeclineSupersed = $Wsus.GetUpdates() | Where-Object {($_.UpdateClassificationTitle -eq "Security Updates") -and ($_.IsSuperseded -eq $True)}
$DeclineSupersed | ForEach-Object -Process {$_.Decline()}
$DeclinedAfter = $KBState.DeclinedUpdateCount

Write-Host "Before we had $DeclinedBefore KB declined, and now  $DeclinedAfter"

2 - Approuver des KB

 Pour approuver des KB de sécurité non approuvées et non remplacées.

# Approve Action
$AproveKB = $Wsus.GetUpdates() | Where-Object {($_.UpdateClassificationTitle -eq "Security Updates") -and ($_.IsSuperseded -eq $false) -and ($_.IsApproved -eq $false) -and ($_.State -ne "NotNeeded")}
$MyTarget = $wsus.GetComputerTargetGroups() | Where-Object {$_.Name -eq "TEST-Workstations"}
$AproveKB[0].ApproveForOptionalInstall($MyTarget)

Attention dans l'exemple ci-dessus nous approuvons les KB "nécessaires" pour un groupe appelé "TEST-Workstations", pensez à modifier la variable "$MyTraget" avec le nom de votre ou vos groupes.

Exemple:

# Approve Action
$ApprovedKB = $Wsus.GetUpdates() | Where-Object {($_.UpdateClassificationTitle -eq "Security Updates") -and ($_.IsSuperseded -eq $false) -and ($_.IsApproved -eq $false) -and ($_.State -ne "NotNeeded")}
$MyTarget = $wsus.GetComputerTargetGroups() | Where-Object {$_.Name -eq "Prod_Servers"}
$AproveKB[0].ApproveForOptionalInstall($MyTarget)

Bonjour à tous,

Aujourd'hui nous allons aborder la problématique du Secure Channel (canal sécurisé) dans une infrastructure Active Directory.

Qu'est ce que le Secure Channel ?

Le Secure Channel ou Canal Sécurisé est un élément vital dans une infrastructure Active Directory. En effet, toute communication entre une station de travail et un contrôleur de domaine AD doit passer via un canal sécurisé.

Il est à noter que le canal sécurisé est également utilisé pour les communications entre deux contrôleurs de domaine.

Quand le canal sécurisé est cassé, toutes les opérations Active Directory liées au canal sont en échec (Tickets Kerberos, stratégies de groupes, ...).

Quand le Secure Channel est cassé

Le signe le plus flagrant d'un problème de canal sécurisé entre un poste et un contrôleur de domaine est le message suivant au démarrage du poste : "The trust relationship between this workstation and the primary domain failed".

La plupart du temps, ceci est du au fait que le mot de passe en usage pour établir le Secure Channel sur le poste concerné est différent du mot de passe du compte ordinateur stocké dans l'AD.

Réparer le Secure Channel

Habituellement, l'étape de réparation passe par les étapes suivantes :

1. Sortie du poste du domaine pour un retour en Workgroup
2. Réinitialisation du compte ordinateur correspondant dans l'Active Directory
3. Réintégration du poste dans le domaine

L'ancienne méthode

Une méthode, plus propre, et qui vous épargnera un redémarrage consiste à réparer le canal sécurisé directement avec une invite de commande.

La commande à utiliser est netdom resetpwd /s:domaincontroller /ud:domain\User /pd:*

La nouvelle méthode

Avec l'avènement de Powershell, une nouvelle commande a fait son apparition : Test-ComputerSecureChannel.

Si la commande renvoie True, c'est que le Secure Channel est fonctionnel entre le poste et le contrôleur de domaine concerné.

Si elle renvoie False, c'est que le Secure Channel n'est plus fonctionnel entre le poste et le contrôleur de domaine concerné.

Il faut l'utiliser avec l'option Repair afin de réparer le Secure Channel.

Le retour de la commande, True ou False, indique le succès ou non de la réparation du Canal Sécurisé.

A noter qu'à partir de Powershell v4.0, l'option Credential permet de préciser les identifiants à utiliser pour réparer le canal sécurisé.

Version Windows 7 / Windows Server 2008 R2 :

Version Windows 8 / Windows Server 2012 R2 :

Dans cette partie nous allons voir comment utiliser la fonction Cleanup via Powershell

1 - Les Variables

La fonction "Cleanup" permet de nettoyer la base du serveur WSUS.

Il est possible de supprimer :

• Les Superseded Updates  ou mises à jour remplacées en Français
• Les Expired Updates ou mises à jour expirées en Français
• Les Obsolete Updates ou mises à jour obsolètes en Français
• Les Compress Updates ou mises à jour inutiles en Français
• Les Obsolete Computers ou les ordinateurs obsolètes en Français
• Les Unneeded ContentFiles ou Fichiers de mise jour inutiles en Français

Dans l'exemple ci-dessous les variables seront par défaut à "$False" il suffit de mettre "$True" pour valider la fonction.

    # Variables de Cleanup: 
# Decline updates that have not been approved for 30 days or more, are not currently needed by any clients, and are superseded by an aproved update. 
[Boolean]$SupersededUpdates = $false 
# Decline updates that aren't approved and have been expired my Microsoft. 
[Boolean]$ExpiredUpdates = $false 
# Delete updates that are expired and have not been approved for 30 days or more. 
[Boolean]$ObsoleteUpdates = $false 
# Delete older update revisions that have not been approved for 30 days or more. 
[Boolean]$CompressUpdates = $false 
# Delete computers that have not contacted the server in 30 days or more. 
[Boolean]$ObsoleteComputers = $True 
# Delete update files that aren't needed by updates or downstream servers. 
[Boolean]$UnneededContentFiles = $false 

2 - La commande

Une fois les variables définies, il faut indiquer le "Cleanup Scope" qui permet d'établir quels paramètres seront nettoyer, pour cela nous utiliserons la commande suivante :

$CleanupScope = New-Object Microsoft.UpdateServices.Administration.CleanupScope($supersededUpdates,$expiredUpdates,$obsoleteUpdates,$compressUpdates,$obsoleteComputers,$unneededContentFiles)

Une fois le "Cleanup Scope" définit, il ne reste plus qu'a exécuter la commande de nettoyage ci-dessous : 

($Wsus.GetCleanupManager()).PerformCleanup($CleanupScope)

Ou

$Cleanup = $Wsus.GetCleanupManager()
$Cleanup.PerformCleanup($CleanupScope)

3 - Bonus

Si vous possédez plusieurs serveurs WSUS, il est possible d'exécuter ce script (dans cet exemple nous ciblons uniquement les Ordinateurs obsolètes, remplacez les "$False" par "$True" pour valider les autres paramètres) :

# Script de Cleanup

$LogCatch = "$env:USERPROFILE\Desktop\LogCatch.txt"

# Détection des WSUS
Get-ADComputer -Filter { (Name -like "*WSUS*") -and (Enabled -eq $true)} | Select-Object -Property DNSHostName | Sort-Object -Property DNSHostName | ForEach-Object {
    $DNSHostName = $_."DNSHostName"
    
#region - Connexion au WSUS
        # Varibles de connexions
            $WsusServer = $DNSHostName
            $WsusPort = "8530"
        # Valeur max de prise en compte d'une machine (ici 30 jours sans connexion au serveur WSUS)
            $thirtydaysago = (get-date).adddays(-30)
            $DaysComputerStale = "30"

        #region - Ouverture de la connexion au serveur 
        $ErrorActionPreference = 'SilentlyContinue'
        Try {
            [void][reflection.assembly]::loadwithpartialname("microsoft.updateservices.administration")
            $Wsus = [microsoft.updateservices.administration.adminproxy]::getupdateserver($WsusServer,$false,$WsusPort)
            $Wsus.Name
            $Log = $Wsus.Name
            }
        Catch {
            Write-Warning "$($WsusServer)<$($WsusPort)>: $($_)" | Add-Content -Path $LogCatch
            $Connection = "Failed"
            $finalWorkSheet.Cells.Item($FinalExcelRow,9) = $Connection
            }
            If ($Log -eq $null){
                Try {
                    $WsusPort2 = "80"
                    [void][reflection.assembly]::loadwithpartialname("microsoft.updateservices.administration")
                    $Wsus = [microsoft.updateservices.administration.adminproxy]::getupdateserver($WsusServer,$false,$WsusPort2)
                    $Wsus.Name
                    }
                Catch {
            Write-Warning "$($WsusServer)<$($WsusPort2)>: $($_)" | Add-Content -Path $LogCatch
                        }
                }
        $ErrorActionPreference = 'SilentlyContinue'
        #endregion - Ouverture de la connexion au serveur
#endregion - Connexion au WSUS

#region - Cleanup
    # Variables de Cleanup: 
    # Decline updates that have not been approved for 30 days or more, are not currently needed by any clients, and are superseded by an aproved update. 
    [Boolean]$supersededUpdates = $false 
    # Decline updates that aren't approved and have been expired my Microsoft. 
    [Boolean]$expiredUpdates = $false 
    # Delete updates that are expired and have not been approved for 30 days or more. 
    [Boolean]$obsoleteUpdates = $false 
    # Delete older update revisions that have not been approved for 30 days or more. 
    [Boolean]$compressUpdates = $false 
    # Delete computers that have not contacted the server in 30 days or more. 
    [Boolean]$obsoleteComputers = $True 
    # Delete update files that aren't needed by updates or downstream servers. 
    [Boolean]$unneededContentFiles = $false 

    $CleanupScope = New-Object Microsoft.UpdateServices.Administration.CleanupScope($supersededUpdates,$expiredUpdates,$obsoleteUpdates,$compressUpdates,$obsoleteComputers,$unneededContentFiles) 

    ($Wsus.GetCleanupManager()).PerformCleanup($CleanupScope)

#endregion - Cleanup

#region - Release des Variables
$Name = $null
$WsusPort = $null
$Wsus = $null
$Log = $null
#endregion - Release des Variables
}

La nomenclature de mes serveurs comporte "WSUS" dans le nom, je passe donc par un "Get-Adcomputer", mais vous pouvez très bien remplacer cela par un "Import-CSV".

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.