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,

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/

Ajout d’un serveur Nano dans le domaine à partir de l’unattend.xml

Nous allons voir comment ajouter un serveur Nano dans le domaine à partir du fichier unattend.xml qui sera exécuté au premier lancement du serveur Nano à l’aide du contenu du fichier blob.

Dans un premier temps, sur votre contrôleur de domaine lancer la commande suivante :

djoin  /provision /domain labo.local /machine HYPV-1 /SAVEFILE HYPV-1

pour le commutateur /domain vous devez préciser le nom de votre domaine.

pour /machine, vous devez préciser le nom de la machine qui sera provisionner dans le domaine

pour /SaveFile, il s’agit du nom de fichier

image

 

Un fichier Blob a été généré

image

 

Observer son contenu en l’ouvrant avec notepad

image

Le contenu de ce fichier devra être présent dans le fichier unattend.xml du serveur entre les balises <AccountData> et </AccountData>.

image

Corps de l’unattend:

<?xml version='1.0' encoding='utf-8'?>  
<unattend xmlns="urn:schemas-microsoft-com:unattend" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
  
  <settings pass="offlineServicing">  
    <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">  
        <OfflineIdentification>                
           <Provisioning>    
             <AccountData></AccountData>  
           </Provisioning>    
         </OfflineIdentification>    
    </component>  
  </settings>  
  
  <settings pass="oobeSystem">  
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">  
      <UserAccounts>  
        <AdministratorPassword>  
           <Value>MonMotDePasse</Value>  
           <PlainText>true</PlainText>  
        </AdministratorPassword>  
      </UserAccounts>  
      <TimeZone>Pacific Standard Time</TimeZone>  
    </component>  
  </settings>  
  
  <settings pass="specialize">  
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">  
      <RegisteredOwner>My Team</RegisteredOwner>  
      <RegisteredOrganization>My Corporation</RegisteredOrganization>  
    </component>  
  </settings>  
</unattend>  

 

Copier coller le contenu entre les balises.

image

 

Depuis un accès Offline, appliquer maintenant le fichier unattend sur le serveur

image

 

Démarrer le serveur

image

 

Authentifier vous avec un compte admin du domaine

image

 

L’authentification a réussi. On remarque également que notre serveur est maintenant dans le domaine.

image

Configuration du rôle container sur un serveur Nano [ Version Technical Preview 5 2016]

 

Pré requis : Avoir installé le Package Container (.cab) dans le serveur Nano.

Exemple via DISM:

image

 

image

 

Nous allons installer sur notre serveur Nano le module qui nous permettra de manipuler des images de Containers.

Exécuter la commande suivante afin de visualiser le module:

Find-Module ContainerImage (l’exécution de cette commande demande un accès à Internet)

image

 

Exécuter la commande suivante pour Installer le module :

Find-Module ContainerImage |install-module –force  (l’exécution de cette commande demande un accès à Internet)

la commande suivante : Get-module –l cont* nous permet de voir que le module est maintenant installé sur le serveur Nano.

image

 

Nous allons maintenant installer l’image Container NanoServer.

Exécuter la commande suivante :

Find-ContainerImage   (l’exécution de cette commande demande un accès à Internet)

image

en TP5,  depuis un serveur Nano, il n’est pas possible de télécharger un Container image à l’aide de la commande Find-ContainerImage.

Afin de contourner le problème, nous allons télécharger le container image NanoServer depuis un autre serveur en version Windows Server 2016 TP5 Full. Puis nous importerons celui ci sur notre serveur Nano.

(Le module ContainerImage doit bien entendu être installé sur le serveur 2016 FULL)

Depuis le serveur 2016 Full, lancer la commande suivante:

Find-ContainerImage

 

image

Ici, contrairement au serveur Nano, il est possible de voir les containers Image disponible.

Nous allons donc sauvegarder en local le container Image NanoServer, puis le copier sur notre serveur Nano et ensuite l’importer dans la configuration de notre serveur Nano.

 

Sur le serveur 2016 FULL créer un répertoire:

mkdir <répertoire-à-créer>

image

 

Puis lancer la commande suivante :

Find-ContainerImage –Name NanoServer | Save-ContainerImage –Path <répertoire-créer>

 

La téléchargement et la sauvegarde est en cours.

image

 

image

 

La sauvegarde est maintenant effective.

image

 

Copions maintenant l’export de notre Container Image sur notre serveur Nano

image

 

image

 

Nous devons maintenant récupérer le script Install-ContainerHost.ps1 qui va nous permettre d’importer notre container Image Nano et activer les fonctionnalités docker sur notre serveur Nano.

 

Le script peut être trouvé à l’adresse suivante :

https://github.com/Microsoft/Virtualization-Documentation/blob/master/windows-server-container-tools/Install-ContainerHost/Install-ContainerHost.ps1

 

Copier le à la racine du serveur.

image

 

Et lancer la commande suivante :

.\Install-ContainerHost.ps1 –PSDirect –WimPath <Export-de-notre-Conteneur>

La configuration est en cours.

image

 

En lançant maintenant la commande Get-ContainerImage, on peut remarquer que notre serveur Nano détient désormais l’image Containeur NanoServer.

image

 

Docker est également installé.

image

 

Nous pouvons désormais créer des containers sur notre Serveur Nano.

Configuration IP d’un serveur Nano

 

Nous allons voir comment configurer l’adressage IP d’un serveur Nano lors de son premier démarrage.

Monter le vhdx de votre image Nano.

image

 

Aller dans la lettre de lecteur monté contenant votre image Nano

image

 

Positionner vous dans le répertoire I:\Windows.

Créer le répertoire Setup si celui ci n’existe pas.

image

 

Créer maintenant dans i:\Windows le répertoire Scripts

image

 

Créer dans le répertoire Scripts un fichier portant le nom setupcomplete.cmd

image

 

Lors du premier démarrage de votre image Nano, le script setupcomplete.cmd sera exécuté.

Ainsi, vous pouvez à partir de ce script, configurer l’interface réseau de votre serveur Nano.

Exemple :

Nous allons configurer sur notre serveur Nano l’adresse IP 192.168.1.11/24 avec comme adresse DNS le 192.168.1.10.

Pour cela, nous allons enregistrer les lignes de commandes suivante dans le setupcomplete.cmd :

PowerShell -Command "& {if ($env:computername -eq 'NANO'){netsh interface ip set address 'Ethernet' static 192.168.1.11 255.255.255.0 192.168.1.254}}"
PowerShell -Command "& {if ($env:computername -eq 'NANO'){netsh interface ipv4 add dnsserver "Ethernet" address=192.168.1.10 index=1}}"

image

Ejecter votre VHD depuis l’explorateur Windows.

Lancer votre serveur Nano.

Le script SetupComplete.cmd s’exécute (car il s’agit du premier lancement du serveur Nano depuis sa génération).

 

image

image

Authentifier vous

image

Nos paramètres IP se sont correctement configurés.

image

 

image

Nested Hyper-V sous NanoServer Technical Preview 4

 

La Technical Preview 4 de Windows Server 2016 est désormais disponible. https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

 

De nouveaux Packages Nano sont désormais disponible.

Vous pouvez construire vos VM nanos avec l’outil NanoServerBuild_x64.

 

Disponible ici : https://onedrive.live.com/?cid=b370cc46ea3ab572&id=B370CC46EA3AB572%21137&authkey=%21ANkLug_PPC-kh-8

 

Présentation ici :  http://blog.piservices.fr/post/Provisionner-des-VHDs-et-VM-Nano-Server.aspx

 

 

Exemple de nouveaux Packages disponible sous TP4

 

clip_image001

 

 

Un package SCVMM même :D

 

clip_image002

 

 

Cocher la case New-VM.

 

Pour activer le Nested sur le/les VMs créées, cocher la case Nested.

Celle-ci autorisera la virtualisation imbriquée.

 

Attention : Pour que le Nested soit fonctionnel, vous devez être sous une build de l’OS Hyperviseur root supportant la fonctionnalité Nested (Exemple : Windows 10 Build 10586)

 

clip_image003

 

 

Cliquer sur Let’s Go pour démarrer les opérations.

(Des fichiers logs sont générés là ou vos VHDs sont créés).

 

clip_image004

 

 

image

 

 

Une fois les opérations finies, votre / vos VM(s) sont créées.

 

 

Démarrer votre VM

clip_image006

 

 

Authentifier vous

clip_image008

 

 

Nous sommes bien en TP4.

clip_image010

 

 

Création d’un VM imbriquée

 

Nous allons maintenant essayer de créer une VM dans notre Nano Server lui-même virtualisé.

 

Enter-PSSession -VMName NanoTP4 -Credential administrator

New-VHD -Path c:\Base.vhdx -SizeBytes 1GB

New-VM -Name "new 3" -MemoryStartupBytes 32MB -VHDPath c:\Base.vhdx

Get-vm | Start-VM

 

On remarque que la VM démarre correctement. Cela signifie que le Nested est fonctionnel.

 

clip_image012

 

En TP3, le démarrage de la VM ne fonctionnait pas.

image

 

 

Vous pouvez désormais créés des labos avec SCVMM en prime avec tout un tas de clusters :) (y)

 

Have Fun !

Provisionner des VHDs et VM Nano Server via le Tool NanoServerBuild

 

Dans ce blog, nous allons voir comment provisionner des VHDs / VM Nano Server à l’aide de l’outil NanoServerBuild.

 

Celui ci va nous permettre de générer un nombre souhaité de VHDs nano servers avec ajout des features et configuration des unattends.

 

Eventuellement, des VMs pourront être créées linké aux différents VHDs créés

(si l’outil est exécuté depuis un hyperviseur.)

 

Pré requis

 

Pour lancer l’outil, .NET 3.5 doit être installé sur votre ordinateur.

L’OS doit être en 64bits.

Positionner la politique d’exécution PowerShell sur Unrestricted:

Set-executionPolicy Unrestricted

 

 

 

Présentation de l’outil

 

Disponible à cette adresse:

https://onedrive.live.com/?cid=b370cc46ea3ab572&id=B370CC46EA3AB572%21137&authkey=%21ANkLug_PPC-kh-8

 

La version 1.0 ne sera disponible que lorsque la release Windows Server 2016 RTM sera sortie.

 

L’outil NanoServerBuild va vous permettre de provisionner simplement et rapidement des VHD(s) / VM Nano Server 2K16.

 

 

Lancer l’outil en tant que administrateur

 

image

 

 

 

L’interface se lance

 

image

 

 

 

 

Dans la section Path, vous devez sélectionner l’emplacement où se trouve les sources du Nano Server pour sa construction.

image

 

 

(Par défaut présent à la racine du média d’installation Windows Server 2016 TP2 et TP3)

 

image

 

 

 

 

La section VHDX vous permet de spécifier les paramètres de configuration pour votre VHD :

 

  • Son emplacement
  • Son nom
  • Sa taille
  • Son type Fixed/Dynamic
  • Son initialisation MBR/GPT

image

 

 

 

Vous pourrez retrouver ici les différents packages présent dans le Path Nano Server précédemment définie pouvant être intégré dans votre VHD Nano pour sa construction.

 

image

 

 

 

Cette fenêtre vous indiquera les éléments manquant pouvant empêcher la construction de votre VHD NanoServer.

 

image

 

 

 

Cette section va vous permettre de :

  • Choisir le nombre de VHDs Nano Server que vous souhaitez créer
  • Démonter le/les VHDs une fois les opérations effectuées
  • Créer des VMs linké à vos VHDs Nano Servers
  • Choisir la mémoire vive à affecter à vos VMs

 

image

 

 

 

La section XML vous permet de configurer et d’appliquer un fichier unattend à vos VMs.

 

image

 

 

 

 

La section copy in.. vous permet de copier le contenu d’un répertoire dans vos VHDs Nano Servers dans \windows\setup\script.

Ainsi vous pouvez par exemple provisionner des scripts qui s’appliqueront à vos Nano Servers en fonction des hostnames affectés.

 

 

image

 

 

 

 

Démonstration

 

Sélectionner le Path de votre répertoire Nano Server

 

image

 

 

Les Features disponibles s’affichent

 

image

 

 

 

 

 

Rappel sur les Features disponible

 

image

 

 

Nous allons sélectionner les packages nécessaire pour que nos VHDs Nano Server soient des VMs qui jouent le rôle de serveur SOFS hébergé au sein d’un cluster.

Sélectionner Guest, FailoverClusters et Storage.

 

 

image

 

 

 

Dans l’exemple ci-dessous, nos VHDs s’appelleront MonNano-XXX (XXX car plusieurs VHDs seront créés).

Ils seront créés à la racine du lecteur C avec une taille de 5GB. Les VHDs seront de type Dynamic et initialisé en MBR.

 

image

 

 

 

Nous allons créer 3 VHD qui ne seront plus montés dans l’explorateur à la fin des opérations.

Nous allons pour chacun de ses VHDs créés, les affecter à des VMs sur notre Hyperviseur avec une taille de 1024Mo pour la mémoire vive.

(La coche New-VM n’est disponible que si l’outil est exécuté sur un Hyperviseur).

 

image

 

 

 

Actuellement, aucune VM n’est présente sur notre Hyperviseur.

 

image

 

 

Sélectionner les valeurs désirés pour votre unattend

 

image

 

 

 

Attention si vous utilisez la rubrique XML :

  • Si vous ne définissez pas de mot de passe, le mot de passe par défaut sera "nano".
  • Si vous ne cochez pas la case ComputerName, chacun de vos VHDs auront pour ComputerName "nano".
  • Si vous cochez la case ComputerName, vos VHD auront pour nom la valeur que vous aurez saisie dans la rubrique VHDX + un incrément basé sur le nombre de VMs que vous allez créer.                          

Exemple : dans notre cas 3 VM seront créés avec le nom MonNano soit : MonNano-1, MonNano-2 et MonNano-3.

 

 

Le bouton aperçu vous permet d’avoir un aperçu du fichier unattend qui sera appliqué avec vos saisies.

 

image

 

 

Exemple:

 

image

 

 

Si vous souhaiter copier le contenu d’un répertoire dans \windows\setup\scripts de vos VHDs, sélectionner alors un répertoire.

 

image

 

 

 

Cliquer sur Go pour lancer les opérations.

 

image

 

 

 

Une fois les traitements finis, votre Hyperviseur disposera de vos VM Nano Servers.

 

image

 

 

 

 

Le contenu de vos VHDs avant leurs démarrages :

 

 

Présence du fichier unattend

 

 

 

clip_image001

 

 

 

 

 

Données copiées dans le répertoire \Windows\Setup\script

 

 

clip_image002

 

 

 

Aperçu des VMs démarrées.

 

 

clip_image002

 

 

clip_image004

 

 

clip_image006

 

 

Enjoy ! Punk

Création d’un cluster SOFS sur Storage Spaces Direct avec nœuds du Cluster sous Windows Server 2016 Nano

 

Nous allons dans ce blog créer un cluster SOFS en utilisant  Storage Spaces Direct (S2D).

Les nœuds du cluster seront des Windows Server 2016 Nano.

Ce blog n’a pas pour vocation de configurer le cluster dans des best practices ( RDMA, réseau CSV, …), mais seulement de présenter l’intégration de S2D dans le cluster.

Pour rappel, Storage Spaces Direct permet de créer un stockage hautement disponible avec le stockage local du serveur. C’est une grande avancée dans le modèle Software Define Storage (SDS) qui va simplifier la gestion des serveurs Hyperconvergés et permettre l’utilisation de certains types de disques comme les disques SATA, les disques NVME, qu’il n’était pas possible d’utiliser précédemment dans les Storage Space Cluster sous Windows 2012.

image

 

Notre Cluster sera constitué de 4 nœuds : Nano1, Nano2, Nano3 et Nano4 avec chacun deux disques disponible.

 

Ajouts des serveurs Nano dans le domaine

 

Depuis un contrôleur de domaine, on provisionne nos 4 serveurs via la commande djoin /provision.

 

Exemple :

djoin.exe /provision /domain labo.local /machine NanoX /savefile C:\odjblobNanoX

 

image

 

Copier les fichiers respectifs générés sur les serveurs Nanos (via les partages administratifs par exemple).

 

Ensuite, on se connecte sur les 4 serveurs Nano depuis l’hyperviseur via PowerShell Direct (nécessite Windows 10 ou Windows Server 2016 pour cette méthode) afin de les intégrer dans le domaine via la commande djoin /requestodj.

 

Exemple :

djoin /requestodj /loadfile C:\odjblobNanoX /windowspath c:\windows /localos

 

Et on reboote les serveurs.

 

image

image

image

image

Désormais, les 4 serveurs Nanos sont dans le domaine.

 

Exemple pour Nano1

 

image

 

 

Maintenant, depuis une machine disposant des outils RSAT FailoverClusters 2K16 dans le domaine, on créé le cluster Cluster-Nano avec les nœuds Nano1, Nano2, Nano3 et Nano4.

New-Cluster -Name "Cluster-Nano" -Node Nano1, Nano2, Nano3, Nano4 –NoStorage

image

 

Depuis la MMC Failover Cluster, on peut désormais voir notre Cluster-Nano.

 

clip_image001

 

Activation du Storage Space Direct sur le cluster

 

Il faut activer au niveau du cluster la fonctionnalité Storage Space Direct via la commande suivante :

 

Get-cluster Cluster-Nano | Enable-ClusterStorageSpacesDirect

 

clip_image003

 

Les DAS de vos nœuds sont visibles dans Enclosures.

 

clip_image005

 

Création du Storage Pool et du Virtual Disk

 

Nous allons maintenant générer un Storage Pool depuis nos disques locaux des nœuds du cluster.

 

clip_image007

 

Spécifier un nom de Storage Pool

 

clip_image009

 

Sélectionner les disques devant participer au Storage Pool (ici sont affichés les 2 disques * 4 nœuds soit 8 disques)

 

clip_image011

clip_image013

clip_image015

Le Storage Pool est désormais créés.

 

clip_image017

 

Nous allons maintenant créer un Virtual Disk sur ce Storage Pool.

 

Clic droit sur le Pool et New Virtual Disk

clip_image019

clip_image021

 

Sélectionner votre Storage Pool précédemment créé.

 

clip_image023

Donner un nom à votre virtual Disk

 

clip_image025

clip_image027

Dans notre exemple, nous allons créer un miroir avec une taille de 12 GB

clip_image029

clip_image031

clip_image033

Cocher la case Create a volume when this wizard closes

clip_image035

 

Créer maintenant le volume. Cliquer sur Next

clip_image037

 

Sélectionner le disque disponible présent au sein du cluster

clip_image039

 

Allouer toute la capacité disponible au volume.

clip_image041

 

N’affecter pas de lettre de montage (inutile car il s’agira d’un volume CSV)

clip_image043

 

Donner un label et formater en ReFS

clip_image045

clip_image047

clip_image049

 

La ressource disque est maintenant disponible.

clip_image051

 

Ajouter ce disque en tant que CSV.

clip_image053

clip_image055

 

Désactiver l’intégrité sur le CSV

Set-FileIntegrity C:\ClusterStorage\Volume1 –Enable $false

 

clip_image057

 

 

Ajout du role SOFS dans le cluster

 

Si désormais vous souhaitez ajouter le rôle SOFS au cluster, vous aurez un message d’erreur.

 

clip_image059

 

Vous devez pour cela activer sur les nœuds du cluster la feature File-Services car actuellement celle-ci est désactivée.

clip_image061

 

 

Ajout de la feature sur les nœuds :

 

 

invoke-command -computer nano1 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

invoke-command -computer nano2 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

invoke-command -computer nano3 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

invoke-command -computer nano4 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

 

clip_image063

 

Désormais, vous pouvez ajouter votre rôle SOFS.

 

clip_image065

clip_image067

clip_image069

clip_image071

clip_image073

 

Il ne vous reste plus qu’à ajouter des partages de fichiers de type SMB Share –Applications sur le CSV reposant sur du Storage Space Direct et vous pourrez héberger vos VMs.

clip_image075

 

 

(Après avoir bien entendu relié le tout via du SMB 3 en exploitant le MultiChannel et le RDMA. Sourire )