Maintenance base WSUS

Il est nécessaire d’effectuer une maintenance sur le serveur WSUS au moins une fois par mois afin d’optimiser les temps de réponse de la base de donnée et libérer du stockage.

Pour cela, on peut utiliser la console graphique mais si jamais la manipulation n’a jamais été faite depuis l’installation du serveur, cela peut produire un timeout et donc ne pas fonctionner.

Il faut suivre cet article : https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/

1) On s’assure qu’aucune synchronisation du serveur n’aura lieu durant la maintenance.
2) On installe sql management studio sur le serveur
3) On se connecte à l’instance
Pour les wid :

Si OS Windows Server 2012, \\.\pipe\MICROSOFT##WID\tsql\query
Si précédent \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

4) On exécute la requête suivante

https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61

5) On lance le script powershell suivant

https://gallery.technet.microsoft.com/scriptcenter/WSUS-Clean-Powershell-102f8fc6

On peut vérifier le nombre de ligne éligibles à la suppression via la procédure stockée

exec spGetObsoleteUpdatesToCleanup

On peut également supprimer les lignes via la commande

exec spDeleteUpdate @localUpdateID="numéro renvoyé dans la commande précédente"
Publicités

Deduplication Windows

Il est possible d’utiliser la déduplication afin de libérer de l’espace disque. Lors de ce processus, 3 composants entrent en jeu:

-l’optimisation
-le garbage collection
-le scrubbing

Les taches planifiés sont créées dans microsoft\windows\déduplication

1)L’optimisation

C’est le processus de déduplication en lui même. Par défaut, il s’exécute en tache de fond avec une priorité faible. C’est la tache planifiée qui se lance toutes les heures. Il est possible de planifier via l’interface graphique pour s’exécuter avec une priorité normale certains jours à certaines heures pendant une certaine durée.

Voici le paramétrage par défaut

2)le garbage collection

Il permet d’effectuer le nettoyage de la mémoire. Il récupère de l’espace disque en supprimant les blocs inutiles qui ne sont plus référencés par les fichiers qui ont été récemment modifiés ou supprimés.

Il s’exécute par défaut une fois par semaine le samedi à 2h45

3)le scrubbing

Il permet le nettoyage des données. Le travail Nettoyage des données identifie toute altération dans le magasin de blocs causée par des défaillances de disque ou des secteurs défectueux.

Il s’exécute par défaut une fois par semaine le samedi à 3h45

 
————————————————————————————
 

Les paramètres de garbage collection et scrubbing ne sont pas des taches planifiées modifiable. Il est nécessaire de passer par powershell pour créer une nouvelle tache planifiée pour cela.

Lancer le job de garbagecollection à 7h du matin pour une durée de 23 heures qui utilise toute la mémoire et les processeurs disponibles avec pour périodicité tous les dimanches.

New-DedupSchedule -Name "WeeklyGarbageCollection" -Type GarbageCollection -DurationHours 23 -Memory 100 -Cores 100 -Priority -Days sunday -Start Get-Date "2016-08-13 07:00:00"

Lancer le job de scrubbing à 7h du matin pour une durée de 23 heures qui utilise toute la mémoire et les processeurs disponibles avec une priorité élevée avec pour périodicité tous les lundi et mardi.

New-DedupSchedule -Name "WeeklyIntegrityScrubbing" -Type Scrubbing -DurationHours 23 -Memory 100 -Cores 100 -Priority -Days monday,tuesday -Start Get-Date "2016-08-13 07:00:00"

Migration WSUS 3 vers 4

Nous allons parler ici du scénario de migration où on garde le même nom et la même IP de serveur afin de n’avoir aucune modification à réaliser en terme de GPO par exemple.

Pour effectuer cette migration, il est nécessaire de récupérer les binaires d’installation et la base de donnée du serveur source et de les intégrer au serveur de destination. Une fois cette manipulation effectuée, il sera nécessaire de regénérer un nouveau GUID sur le second serveur afin de s’assurer de son unicité suite à l’import de la BDD.

Procédure à suivre sur le serveur source:
1)Copier le répertoire WSUScontent vers un emplacement réseau
2)Faire une sauvegarde de la base de donnée en .bak via sql management studio
3)Sortir le poste du domaine
4)Eteindre la machine

Procédure à suivre sur le serveur de destination:

1)Intégrer le poste dans le domaine avec le nom de la machine source
2)Installer le rôle WSUS
3)Remplacer le contenu du WSUSContent par celui présent sur le réseau (étape 1 précédente)
4)Supprimer la base de donnée SUSDB via sql management studio
5)Restaurer la base de donnée du serveur source
6)exécuter la commande ci dessous

c:\programfiles\update services\Tools\wsusutil.exe postinstall

7) exécuter le script PowerShell ci dessous

$updateserver=get-wsusserver
$config=$updateserver.getconfiguration()
$config.serverid=[System.Guid]::NewGuid()
$config.save()

8)exécuter la commande ci dessous

c:\programfiles\update services\Tools\wsusutil.exe postinstall

Restauration du sysvol FRS

Dans le cas d’une infrastructure FRS, il arrive fréquement que la réplication SYSVOL ne soit plus opérationnelle.

On peut alors la réparer via diverses solutions :

  1. Dépromotion + repromotion du serveur impacté
  2. Utilisation d’une restauration non authoritaire
  3. Utilisation d’une restauration autoritaire

1. Dépromotion et repromotion

Cette solution sera utilisée si la méthode numéro 2 ne fonctionne pas et que la méthode 3 n’est pas envisageable dans certaines infrastructure de taille importante.

2. Utilisation d’une restauration non autoritaire

Ce cas est le premier à essayer. Il permet de placer un controleur de domaine dans un état d’esclave et recopier le sysvol depuis un autre DC du domaine.

Pour cela il faut aller modifier la valeur de la clé burflag de 0 à D2 à l’emplacement

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

Et redémarrer ensuite le service. La clé passe alors à la valeur 0.

Au niveau du journal d’évènements on voit alors l’évènement 13565 pour le début d’une réplication ne faisant pas autorité et 13516 une fois la manipulation terminée.

3. Utilisation d’une restauration autoritaire

Ce cas la permet de dire dans le domaine qu’on a un serveur qui fait autorité pour la réplication et TOUS les autres DC. Il est donc nécessaire de positionner la valeur D4 de la clé en partie 2. pour le contrôleur faisant autorité et D2 pour tous les autres DC. On redémarre ensuite le DC qui a la valeur D4 et ensuite les autres DC à D2.

La suivi se fait via l’évènement 13566  pour le démarrage d’une restauration faisant autorité et 13516 une fois la réplication terminée.

Activation basée sur l’AD / KMS

Lorsqu’on souhaite activer les clients/serveurs on peut utiliser KMS ou alors l’activation basée sur l’AD. Cette dernière n’est disponible que pour des OS minimum windows 8 /2012. Si jamais les 2 activations sont disponibles alors les postes compatibles utiliseront d’abord l’AD et ensuite le KMS. Le fonctionnement pour l’activation concernant l’AD s’effectue lors de la jonction au domaine pour une validité de 180 jours renouvelée tous les 7 jours.

Si on veut supprimer l’activation basée sur l’AD il faut supprimer les objets présents dans le container suivant dans la console ADSI edit :

 partition de configuration / services / microsoft spp / activation objects

2017-08-28_11h51_55.png