PI Services

Le blog des collaborateurs de PI Services

Active Directory : Migration SYSVOL de FRS vers DFS-R - Déroulement (Partie 2)

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 :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR

 

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

Etat  Etat de transition 
 Etat 4 Preparing (valable uniquement pour les RODC)
 Etat 5  Waiting for initial synchronization
 Etat 6  Redirecting
 Etat 7  Eliminating
 Etat 8  Undo redirecting
 Etat 9  Undo preparing

 

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.

Active Directory : Migration SYSVOL de FRS vers DFS-R - Préparation (Partie 1)

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.

Windows Server Core : Récupérer la main sur une console fermée

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 :

Application

Server Core

Server with Desktop Experience

Command prompt

available

available

Windows PowerShell/ Microsoft .NET

available

available

Perfmon.exe

not available

available

Windbg (GUI)

supported

supported

Resmon.exe

not available

available

Regedit

available

available

Fsutil.exe

available

available

Disksnapshot.exe

not available

available

Diskpart.exe

available

available

Diskmgmt.msc

not available

available

Devmgmt.msc

not available

available

Server Manager

not available

available

Mmc.exe

not available

available

Eventvwr

not available

available

Wevtutil (Event queries)

available

available

Services.msc

not available

available

Control Panel

not available

available

Windows Update (GUI)

not available

available

Windows Explorer

not available

available

Taskbar

not available

available

Taskbar notifications

not available

available

Taskmgr

available

available

Internet Explorer or Edge

not available

available

Built-in help system

not available

available

Windows 10 Shell

not available

available

Windows Media Player

not available

available

PowerShell

available

available

PowerShell ISE

not available

available

PowerShell IME

available

available

Mstsc.exe

not available

available

Remote Desktop Services

available

available

Hyper-V Manager

not available

available

 A bientôt,

[Powershell] Excel ne s'enregistre pas via le Planificateur de tâches

Lancer un script Powershell via le planificateur de tâches ne pose aucun problème, en revanche si ce dernier souhaite utiliser Excel (par l'intermédiaire de la commande "new-object -comobject excel.application") on peut rencontrer un problème.

Je dis "on peut" car cela fonctionne si l'on a pas coché la case "Run Whether user is logged on or not", en revanche si cette dernière est cochée, Excel ne sera pas en mesure d'enregistrer le fichier.

Pourquoi ?

Par défaut l'application Excel s'exécute avec le compte "Utilisateur exécutant (The Launching User)", mais si j'utilise une tâche planifiée qui ne nécessite pas que je sois connecté Excel ne parvient pas a déterminer qui fait appel à lui.

Que Faire ?

Simplement en déclarant qui  exécute l'application Excel via la MMC -> Services des composants.

Je vous renvoie au point 2 (Gestion de l'Excel distant) de mon précédent article : [Powershell] Ecrire dans un Excel distant.

Sécurité : Windows KB pour Ransomware – PETYA

Le rançongiciel Petya est apparu fin juin en Ukraine pour ensuite se propager rapidement partout dans le monde.

Il s’agirait d’une variante de WannaCrypt qui était apparu en début d’année.

 

Se protéger

Si vous n’avez pas encore été infectée, vous devez vérifier que vos postes disposent des dernières mises à jour et de les installer si ce n’est pas le cas.

Pour agir rapidement vous pouvez installer uniquement la KB qui correspond à votre système d’exploitation en regardant la liste sur cette article https://blog.piservices.fr/post/2017/05/30/securite-kb-pour-wanna-cry et de se rendre sur le catalogue de Microsoft pour le télécharger http://www.catalog.update.microsoft.com/home.aspx.

 

Vérifier avec WSUS

Si vous disposez d’un serveur WSUS vous pouvez vérifier depuis la console si votre parc informatique est protégé. Pour se faire il faut se rendre dans l’onglet Updates -> Security Updates -> Search

clip_image002

Dans la fenêtre qui apparaît vous devez rentrer la KB souhaitez par exemple : 4012212

clip_image003

Lorsque vous regardé le report de la KB (en double cliquant dessus) vous verrez :

  • La description de la KB
  • Les groupes qui approuvent cette KB
  • L’état de déploiement par rapport à vos machines

clip_image004

Microsoft a également sorti un script qui permet de savoir si votre machine dispose du patch ou non. Le seul prérequis est de disposer au minimum de Windows PowerShell 2.0. https://support.microsoft.com/fr-be/help/4023262/how-to-verify-that-ms17-010-is-installed

Voici le script :

[reflection.assembly]::LoadWithPartialName("System.Version")
$os = Get-WmiObject -class Win32_OperatingSystem
$osName = $os.Caption
$s = "%systemroot%\system32\drivers\srv.sys"
$v = [System.Environment]::ExpandEnvironmentVariables($s)
If (Test-Path "$v")     {     Try         {         $versionInfo = (Get-Item $v).VersionInfo         $versionString = "$($versionInfo.FileMajorPart).$($versionInfo.FileMinorPart).$($versionInfo.FileBuildPart).$($versionInfo.FilePrivatePart)"         $fileVersion = New-Object System.Version($versionString)         }     Catch         {         Write-Host "Unable to retrieve file version info, please verify vulnerability state manually." -ForegroundColor Yellow         Return         }     }
Else     {     Write-Host "Srv.sys does not exist, please verify vulnerability state manually." -ForegroundColor Yellow     Return     }
if ($osName.Contains("Vista") -or ($osName.Contains("2008") -and -not $osName.Contains("R2")))     {     if ($versionString.Split('.')[3][0] -eq "1")         {         $currentOS = "$osName GDR"         $expectedVersion = New-Object System.Version("6.0.6002.19743")         }      elseif ($versionString.Split('.')[3][0] -eq "2")         {         $currentOS = "$osName LDR"         $expectedVersion = New-Object System.Version("6.0.6002.24067")         }     else         {         $currentOS = "$osName"         $expectedVersion = New-Object System.Version("9.9.9999.99999")         }     }
elseif ($osName.Contains("Windows 7") -or ($osName.Contains("2008 R2")))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.1.7601.23689")     }
elseif ($osName.Contains("Windows 8.1") -or $osName.Contains("2012 R2"))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.3.9600.18604")     }
elseif ($osName.Contains("Windows 8") -or $osName.Contains("2012"))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.2.9200.22099")     }
elseif ($osName.Contains("Windows 10"))     {     if ($os.BuildNumber -eq "10240")         {         $currentOS = "$osName TH1"         $expectedVersion = New-Object System.Version("10.0.10240.17319")         }     elseif ($os.BuildNumber -eq "10586")         {         $currentOS = "$osName TH2"         $expectedVersion = New-Object System.Version("10.0.10586.839")         }     elseif ($os.BuildNumber -eq "14393")         {         $currentOS = "$($osName) RS1"         $expectedVersion = New-Object System.Version("10.0.14393.953")         }     elseif ($os.BuildNumber -eq "15063")         {         $currentOS = "$osName RS2"         "No need to Patch. RS2 is released as patched. "         return         }     }
elseif ($osName.Contains("2016"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("10.0.14393.953")     }
elseif ($osName.Contains("Windows XP"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("5.1.2600.7208")     }
elseif ($osName.Contains("Server 2003"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("5.2.3790.6021")     }
else     {     Write-Host "Unable to determine OS applicability, please verify vulnerability state manually." -ForegroundColor Yellow     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("9.9.9999.99999")     }
Write-Host "`n`nCurrent OS: $currentOS (Build Number $($os.BuildNumber))" -ForegroundColor Cyan
Write-Host "`nExpected Version of srv.sys: $($expectedVersion.ToString())" -ForegroundColor Cyan
Write-Host "`nActual Version of srv.sys: $($fileVersion.ToString())" -ForegroundColor Cyan
If ($($fileVersion.CompareTo($expectedVersion)) -lt 0)     {     Write-Host "`n`n"     Write-Host "System is NOT Patched" -ForegroundColor Red     }
Else     {     Write-Host "`n`n"     Write-Host "System is Patched" -ForegroundColor Green     }
#

Voici le résultat de se script exécuté sur un poste patché et non patché.

clip_image005

clip_image006

 

Information :

Si vous êtes déjà touché par le rançongiciel, la première chose à faire est d’isoler tous les équipements identifiés comme étant contaminés en les débranchant du réseau afin de contenir l’action du programme. De plus vous devez si possible mettre en veille prolongé la machine ou de la mettre hors tension pour arrêter l’action du programme et de ne surtout pas payer la rançon.

Vous pouvez lire également deux notes de l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) qui permet de savoir quelle attitude adopter avant et après une attaque rançongiciel.

http://www.cert.ssi.gouv.fr/site/CERTFR-2017-INF-001/CERTFR-2017-INF-001.html

http://www.ssi.gouv.fr/actualite/alerte-campagne-de-rancongiciel-3/

Sécurité : Windows KB pour Wanna Cry

 

Suite à l'attaque du virus Wanna Cry, tout le monde a souhaité corriger la faille de sécurité au plus vite.

Avec tout ce qu'on a pu lire ou trouver sur internet on ne sait plus vraiment qui fait quoi et si nous sommes réellement protégé.

Liste des KB de Sécurité

Voici la liste des KB de sécurité couvrants la faille (pour information les KB se remplacent d'un mois à l'autre : exemple la KB du mois d'avril remplace celle de Mars):

  1. Pour Windows XP, Vista, 8, Windows Server 2003 et 2008 : 
    1. Mars 2017
      1. KB4012598
  2. Pour Windows 7 SP1 et Windows Server 2008 R2 SP1:
    1. Mars 2017
      1. Security only update : KB4012212
      2. Monthly Rollup : KB4012215
      3. Preview of Monthly Rollup : KB4012218
    2. Avril 2017
      1. Security only update : KB4015546
      2. Monthly Rollup : KB4015549
      3. Preview of Monthly Rollup : KB4015552
    3. Mai 2017
      1. Security only update : KB4019263
      2. Monthly Rollup : KB4019264
      3. Preview of Monthly Rollup : KB4019265
  3. Pour Windows Server 2012 :
    1. Mars 2017
      1. Security only update : KB4012214
      2. Monthly Rollup : KB4012217
      3. Preview of Monthly Rollup : KB4012220
    2. Avril 2017
      1. Security only update : KB4015548
      2. Monthly Rollup : KB4015551
      3. Preview of Monthly Rollup : KB4015554
    3. Mai 2017
      1. Security only update : KB4019214
      2. Monthly Rollup : KB4019216
      3. Preview of Monthly Rollup : KB4019218
  4. Pour Windows 8.1 et Windows 2012 R2 :
    1. Mars 2017
      1. Security only update : KB4012213
      2. Monthly Rollup : KB4012216
      3. Preview of Monthly Rollup : KB4012219
    2. Avril 2017
      1. Security only update : KB4015547
      2. Monthly Rollup : KB4015550
      3. Preview of Monthly Rollup : KB4015553
    3. Mai 2017
      1. Security only update : KB4019213
      2. Monthly Rollup : KB4019215
      3. Preview of Monthly Rollup : KB4019217
  5. Pour Windows 10 (Release 1511) :
    1. Mars 2017
      1. KB4013198
      2. KB4016636
    2. Avril 2017
      1. KB4015219
    3. Mai 2017
      1. KB4019473
  6. Pour Windows 10 (Release 1607) :
    1. Mars 2017 
      1. KB4013429
      2. KB4015438
      3. KB4016635
    2. Avril 2017
      1. KB4015217
    3. Mai 2017
      1. KB4019472
      2. KB4023680
  7. Pour Windows 10 LTSB : 
    1. Mars 2017 
      1. KB4012606
      2. KB4016637
    2. Avril 2017
      1. KB4015221
    3. Mai 2017
      1. KB4019474

En espérant que cela pourra vous servir.

Pour télécharger les KB : http://www.catalog.update.microsoft.com/home.aspx

 

 

Windows Server 2012 R2 : Erreur lors du déploiement du rôle RDS

Lors du déploiement du Rôle RDS sur Windows Server 2012 R2, il se peut que vous rencontriez l'erreur suivante :

"Le serveur est en attente de redémarrage et doit être redémarré."

 

Cette erreur se présente lorsque si vous avez récemment passé une mise à jour ou installer un rôle ou une fonctionnalité sans redémarrer.

Si même après avoir redémarré cela ne change rien, vérifier si la clé de registre suivante existe :

"HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations"

Si elle existe faites un backup de votre registre, puis supprimez la clé.

Normalement vous pouvez maintenant installer le Rôle RDS sans soucis. 

 

Windows Serveur : Extraction des configurations DHCP

Attention ne s'applique qu'à partir de  Windows Server 2012 et Windows 8.

Comment connaitre rapidement les configurations DHCP du domaine? Eh bien, avec Powershell.

 

Lister les serveurs DHCP du domaine:

Pour lister les serveurs DHCP du domaine vous pouvez utiliser la commande:

Get-DhcpServerInDC

Cette commande vous retournera par défaut :

  1. l'adresse IP du ou des serveurs
  2. Le nom Dns du ou des serveurs

Lister les scopes DHCP:

Pour lister les scopes DHCP et leurs configurations vous pouvez utiliser la commande suivante:

Get-DhcpServerv4Scope

Par défaut cette commande vous retournera les éléments suivants:

  1. L'étendue
  2. Le masque sous réseau
  3. Le Nom du scope
  4. L'état (Actif ou Inactif)
  5. L'adresse IP de début
  6. L'adresse IP de fin
  7. La durée des baux

Bien sur il est possible de récupérer d'autres informations si vous le souhaitez.

Obtenir des informations sur les scopes:

Pour obtenir des informations sur l'utilisation des scopes vous pouvez utiliser la commande suivante:

 

Get-DhcpServerv4ScopeStatistics

 

Cette commande retourne :

  1. L'étendue
  2. Le nombre d'adresses libres
  3. Le nombre d'adresses utilisées
  4. Le pourcentage d'utilisation
  5. Le nombre d'adresses réservées
  6. Le nombre d'adresses en attente de distribution (normalement 0)
  7. Le nom de l'étendue globale

Peut on scripter tout ça?

Il vous est possible d'exécuter toutes ces commandes à distance via "invoke-command" ou "Enter-PSSession" sauf la commande "Get-DhcpServerInDC".

Donc il est possible de scripter toutes ces commandes et avoir une belle extraction sans se connecter au serveur à condition de déjà posséder la résultante de  "Get-DhcpServerInDC".

Sinon vous pouvez aussi exécuter un script depuis le serveur, mais bon ça, c'est quand même moins "Secure".

Plus d'informations sur : 

https://technet.microsoft.com/library/jj590751(v=wps.620).aspx

 

 

.NET Framework : Installation du .NET 3.5 sous Windows Server 2012 R2

Bonjour à tous !

L'article d'aujourd'hui rentre dans la catégorie "trucs et astuces", mais de celles qui vous feront gagner beaucoup de temps.

En effet, l'installation de la fonctionnalité .NET Framework version 3.5 sous Windows Server 2012 R2 n'a jamais été une sinécure.

La faute en revient à la fonctionnalité Features on Demand introduite avec Windows Server 2012. Afin de rentre le dossier d'installation de Windows Server 2012 moins volumineux, Microsoft a décidé que les fichiers nécessaires pour installer les rôles et fonctionnalités de Windows Server ne seraient plus présents en totalité sur le disque dur local de l'OS. En conséquence, l'installation de certaines fonctionnalités requiert une source externe (ISO ou ressources sur le réseau) et la fonctionnalité .NET Framework 3.5 en fait partie.

La méthode classique

Concrètement, cela se traduit par un chemin à renseigner vers les sources externes Windows Server lors de l'installation de la fonctionnalité .NET 3.5 au sein du Gestionnaire de Serveur.

Ces sources peuvent être une ISO que vous aurez préalablement monté ou des fichiers stockés sur une ressource réseau.

Si vous ne précisez rien dans le chemin des sources, le Gestionnaire de Serveur utilisera Windows Update comme moyen pour télécharger les sources manquantes.

Et c'est là "tout le sel de l'opération", à savoir que si le serveur est managé par un WSUS, le téléchargement des sources externes via Windows Update n'est pas possible et si vous n'avez pas l'ISO Windows Server sous la main, il vous faudra la transférer et vous n'avez peut être pas le temps, ni la bande passante pour envoyer 4,6 Go !

Heureusement, il existe une alternative.

La méthode Windows Update

La méthode suivante vise à permettre le téléchargement des sources manquantes directement via Windows Update, même si le serveur est dans le périmètre de gestion d'un serveur WSUS.

Nous allons donner ici la méthode "unitaire" pour passer la modification, mais celle-ci est très facilement adaptable en GPO.

1) Pour se faire, ouvrez la console GPEdit.msc sur la machine concernée.

2) Allez dans Computer Configuration -> Administrative Templates -> System

3) Allez à l’option Specify settings for optional component installation and component repair.

4) Passez le paramètre à Enabled si celui-ci est à Disabled ou Not Configured.

5) Cochez l'option Contact Windows Update directly to download repair content instead if Windows Server Update Services (WSUS). Cliquez sur Apply pour valider la modification.

6) Passez la commande GPUpdate /force dans une invite de commande afin que le poste prenne en compte la modification dans ses paramètres de mise à jour.

7) Relancez l'installation de la fonctionnalité .NET Framework 3.5 depuis le Gestionnaire de Serveur, en laissant l'Alternate File Path vide. L'installation devrait désormais être fonctionnelle.

Identifier le certificat correspondant à l’attribut AD UserCertificate ou cACertificate

Dans le cadre de la gestion des certificats dans Active Directory, il arrive que l’on retrouve des valeurs de ce type pour les attributs UserCertificate ou CaCertificate:

 image

Ce type de champ est difficilement lisible et cela peut donc complexifier la tâche lorsque l’on veut supprimer un certificat déployé en doublon, ou tout simplement un certificat avec des informations erronées.

Pour rapidement différencier les certificats il suffit de suivre les étapes suivantes:

Copier le contenu Hexadécimal dans un fichier texte :

image

image

image

Exécuter la commande suivante :

Certutil –decodehex C:\Temp\HexValue.txt C:\Temp\OutputCert.cer

image

Le résultat de la commande est un fichier .cer que l’on peut ouvrir et qui contiendra les attributs du certificat de manière lisible, ces opérations doivent être répétées sur les différentes entrées pour chaque certificat à identifier.

image

image