Introduction :

Cette article va vous montrer comment basculer d’un environnement de gestion SG vers un environnement de gestion Sophos Central.

Note : Les boitiers SG (ancienne gamme Sophos) permettent de jouer le rôle de “serveur antivirus”. 

Prérequis :

• Accès à la console d’administration SOPHOS SG et SOPHOS Central.
• Avoir créé ou importé vos utilisateurs dans SOPHOS Central.
  • Pour que les utilisateurs remontent dans Sophos Central il faut au préalable mettre en place l’outil de synchronisation Sophos.

Déploiement :

La première étape consiste à s’identifier sur SOPHOS XG et de désactiver la « Tamper protection » sur tous les utilisateurs.

Pour réaliser cette action la méthode la plus simple est de créer un groupe réunissant tous les utilisateurs à migrer et de désactiver la fonction :

La deuxième étape consiste cette fois ci à s’identifier sur SOPHOS Central et d’envoyer email d’installation aux utilisateurs concerné par la migration  :

La dernière étape quant à elle, est de lancer l’exécutable téléchargé à partir du mail reçu :

L’installation doit être lancé en tant qu’administrateur et prend environ 15 minutes. Pendant ce lapse de temps le logiciel va désinstaller l’ancien antivirus, télécharger le nouveau et l’installer.

Une fois l’opération fini vous allez voir un nouveau logo apparaitre :

Configuration

Sophos Central permet comme à l’instar de SOPHOS SG de créer des groupes pour gérer l’administration. Le plus avec SOPHOS central est qu’il distingue deux catégories. La première est « User and Computer Policies » et la seconde « Server Polices ».

Voici la liste des paramètres qui peuvent être modifié pour les deux catégories.

Fonctionnalité Innovante

La nouveauté de Sophos Central est le module Intercept X qui contient plusieurs outils dont CryptoGuard qui empêche les ransomwares et la Root Cause Analysis.

La RCA permet en cas d’attaque subit d’analyser en profondeur et de donner les détails de l’attaque.

Pour accéder à cette l’interface il faut se rendre dans l’onglet « Root Cause Analysis » puis de sélectionner l’attaque souhaité.

Trois Onglet s’offre à vous.

Overview : Regroupant les informations essentielles de l’attaque QUOI, OU, QUAND et QUI.

Artifacts : Liste tous les fichiers, adresses IP, Processus, clé de registre et toutes les connexions que l’attaque ai touché. Que ce soit en lecture, écriture, connexion.

Visualize : Montre graphiquement comment l’attaque c’est propagé.

Il suffit ensuite de cliquer sur la bulle qui nous intéresse pour nous afficher le détail.

Contexte :

Le problème ci-dessous a été rencontré suite à la suppression du certificat auto-signé d’un Serveur Microsoft Exchange 2013 depuis la console MMC :

Problème rencontré :

Après avoir exécuté quelques mises à jour et redémarré le serveur, le message suivant apparaissait à l’ouverture d’une session PowerShell :

Analyse :

L’observateur d’évènement est un bon outil qui permet d’avoir plus d’information sur une erreur rencontrée. Dans notre cas l’observateur a noté l’Event ID : 15021

« An error occurred while using SSL configuration for endpoint 0.0.0.0:444.  The error status code is contained within the returned data. »

Comme il est impossible de vérifier depuis l’environnement de ligne de commande Exchange Management Shell à quel site Web IIS est attribué un certificat Exchange (la cmdlet Get-ExchangeCertificate permet uniquement de voir que le certificat est associé à IIS sans préciser sur quel site Web), nous allons passer par IIS (Internet Information Services).

Pour se faire nous ouvrons IIS Manager depuis Server Manager :

Note :

Lors de l’installation d’Exchange 2013 celui-ci va créer deux sites Web dans IIS qui doivent avoir ce certificat affecté :

- Default Web Site

- Exchange Back End

Par défaut c’est le site Web Exchange Back End qui a une liaison au port 444 pour le HTTPS. Ce qui correspond à l’Event du dessus.

Sur IIS nous sélectionnons Exchange Back End


Dans l’onglet Edit Site clic droit sur “Bindings” :


Double cliquer sur “https”:

Nous nous apercevons qu’il n’y aucun certificat assigné.

Solution :

Pour résoudre le problème, il suffit de régénérer un certificat auto signé soit avec le centre d’administration Exchange soit en PowerShell.

Une fois le certificat en place nous relançons PowerShell et nous pouvons constater que celui-ci arrive à se connecter au serveur.

Introduction :

Cette article va vous montrer comment migrer un DHCP failover existant de Windows server 2012 à Windows server 2016

Installation :

Installer le rôle DHCP sur les deux nouveaux serveurs.

Sur un des nouveaux serveurs créer deux répertoires : export et backup avec la commande mkdir. Par la suite toutes les commandes seront à effectuer sur ce serveur

Exporter la configuration DHCP de l’ancien Serveur en exécutant la commande suivante :

Export-DhcpServer –ComputerName nameoldserver –File C:\export\naomeoldserverexp.xml -Verbose

Importer la configuration sur le nouveau serveur DHCP avec la commande suivante

Import-DhcpServer –ComputerName DHCP2012R2-1 –File C:\export\DHCP2012-1exp.xml -BackupPath C:\backup\ -ServerConfigOnly -Verbose -Force

Note : Le paramètre « -BackupPatch » est utilisé pour sauvegarder la database du serveur actuel avant toute modification dans le cadre de la migration. Pour annuler l’opération de migration il suffit d’utiliser la commande Restore-dhcpServer suivit du paramètre –path en spécifiant le répertoire backup.

Configuration :

Pour configurer le mode DHCP Failover il faut se rendre dans l’interface DHCP du nouveau serveur et de cliquer sur Configure Failover

Choisir les scopes qui vont être répliqués

Sélectionner le second serveur

Configurer le Failover a isopérimètre avec l’ancien Failover.

Pour vérifier que le Failover est en place utiliser la commande suivante :

Get-DhcpServerv4Failover

Désinstaller l’ancien DHCP :

Une fois le nouveau DHCP Failover en place il faut supprimer l’ancien. Pour ce faire nous allons commencer par retirer la relation entre les deux avec la commande :

Remove-DhcpServerv4Failover –Name nameofrelationship

Une fois la commande réalisée avec succès, il faut arrêter les deux anciens DHCP depuis l’interface :

Si aucun effet de bord ce produit, Il ne reste plus qu’à désinstaller les rôles sur les deux anciens serveurs :

Contexte

La téléphonie d'entreprise est une pièce importante du SI. La migration de celle-ci est un projet majeur qui doit être bien préparé. Cet article divisé en trois parties est un retour d'expérience sur la migration d'une téléphonie VOIP/TOIP vers une Skype for Business. La première partie traitera des possibilités qu'offre la solution Skype for Business. La seconde partie traitera des différents aspects qui doivent être pris en compte lors de la migration. Enfin la troisième partie traitera des solutions connexes à Skype for Business qui d'augmenter le catalogue de fonctionnalités de la solution.

Les architectures possibles

Le déploiement de la téléphonie à travers Skype for Business est possible de trois façon :

• Architecture OnPremise
• Cloud PBX
• PSTN Calling (à venir)

L'architecture OnPremise implique que l'ensemble de la solution soit hébergé en interne. L'architecture Cloud PBX correspond à une architecture Skype for Business Online (Office 365) et une sortie PSTN en interne. L'architecture PSTN Calling est quant à elle entièrement online. Cette architecture n'est pas encore disponible en France. Les différentes architectures sont définies au lien suivant : https://technet.microsoft.com/en-us/library/mt612869.aspx.

Mon retour d'expérience porte sur un déploiement entièrement OnPremise. L'ensemble de l'architecture déployée l'a été directement au DataCenter du client.

Une infrastructure redondée

La téléphone est un élément important dans une société, son architecture doit donc être hautement disponible. De plus, contrairement à la messagerie la voix est un service en temps réel, l'architecture doit également être réactive.

Ces deux contraintes (haute dispo et performance) compliquent le design de l'architecture.

Architecture physique ou virtuelle ?

Pour Skype for Business, Microsoft supporte une architecture composée de machines physiques ou virtuelles. Cependant Microsoft recommande fortement une architecture physique. Cette recommandation s'appuie sur le besoin de la performance et pour éviter tous problèmes liés à la couche de virtualisation.

Pool de serveurs et multi-sites

Skype for Business intègre nativement un système de pool de serveurs afin de gérer la haute disponibilité du service. Il est ainsi possible d'avoir une architecture redondée sur un seul site.

Bien sur cette haute disponibilité native n'est pas à toute épreuve si l'architecture est présente sur un seul site. Avoir une architecture multi-sites permet de se prémunir des risques tels que les inondations, les feux, les coupures de liens...

Les rôles à déployer

Pour pouvoir déployer la téléphonie, il est indispensable de déployer les rôles Skype suivants :

• Front-End : serveur principal où les clients se connectent, il est recommandé d'en avoir entre 3 et 12 dans un pool
• Back-End : serveur SQL qui contient la configuration (une mise en miroir de la base de données est recommandée)
• Médiation : serveur nécessaire pour la voix, il sert d'interconnexion entre Skype et le monde téléphonique
• Edge : serveur qui permet la communication avec et depuis l'extérieur
• Reverse Proxy (rôle non Skype) : serveur qui permet la publication de tous les services web

Il est possible également de déployer les rôles suivants :

• Directeur : serveur qui permet d'authentifier les utilisateurs avant de transmettre la demande de connexion au Front-End. Il permet de ne pas faire tomber les Front-End en cas d'attaque (type DDOS)
• Persistent Chat : serveur de conversations permanentes, il permet d'avoir des salles de conversations multi-utilisateurs 
• Watcher Node : serveur qui exécute des transactions synthétiques afin d'avoir plus de rapport dans SCOM  
• Office Web Apps (rôle non Skype) : serveur qui permet de partager des PowerPoint dans Skype

Enfin pour que la téléphonie fonctionne il est nécessaire d'avoir une passerelle PSTN.

Ce qu'il faut retenir

Il est possible de faire différentes architectures de Skype for Business. Celle-ci doit être faite en fonction des besoins. 

Voilà qui conclut la première partie de mon retour d'expérience. A bientôt pour la suite !

Contexte

Cet article divisé en trois parties est un retour d'expérience sur la migration d'une téléphonie VOIP/TOIP vers une Skype for Business. Voici la seconde partie qui traitera des différents aspects qui doivent être pris en compte lors de la migration.

Préparer la migration

Choix des terminaux

Le choix des nouveaux terminaux est un élément important de la migration. De nombreux modèles de téléphones et de casques sont compatibles avec Skype for Business. Voici les principaux facteurs de décisions :

• Qualité du son (entrant et sortant)
• Qualité générale du produit : est-il solide ?
• Ergonomie / prise en main / confort
• Support : quelles parties du téléphone / casque peut-on changer (câble, coussinets, mousse...) ? peut-on changer facilement ces pièces ?
• Prix
• Possibilité d'approvisionnement du fournisseur

Ce choix doit être fait à l'aide d'utilisateurs et il est également conseillé de prévoir différentes gammes de produits en fonction des utilisateurs (utilisateur standard, VIP...).

Ne rien oublier !

Le monde de la téléphonie est vaste et ne se limite pas uniquement aux téléphones des utilisateurs.

De nombreuses autres solutions utilisent les lignes téléphoniques classiques tels que :

• Les fax ou les serveurs de fax
• Les timbreuses
• Les centres d'appel (Service Desk par exemple) et les groupements d'appels (cellule voyage par exemple)
• Les accueils
• Les relations entre patrons et secrétaires

Exceptions

Parmi les nombreuses solutions qui utilisent les lignes téléphoniques, certaines doivent utiliser des lignes classiques et ne doivent pas être migrées :

• Les ascenseurs
• Les alarmes

Maquette

Comme dans de nombreux projets, monter une architecture de recette est fortement recommandé. Celle-ci doit être le plus ressemblant possible à l'architecture de production. Cette maquette permettra d'effectuer différents tests : ajout/suppression d'un rôle, modification d'une option, tests de failover...

Conclusion

La migration de la téléphonie doit être bien préparée. Un grand nombre de décisions sont à prendre avant de lancer le projet. Certains choix prennent plusieurs semaines avant d'être validé (choix des terminaux par exemple). Ce temps d'analyse et de décisions est impératif pour éviter les problèmes durant la phase de migration.

Voilà qui conclut la seconde partie de mon retour d'expérience. A bientôt pour la suite !

Contexte

Cet article divisé en trois parties est un retour d'expérience sur la migration d'une téléphonie VOIP/TOIP vers une Skype for Business. Voici la troisième partie qui traitera des solutions connexes à Skype for Business afin d'augmenter le catalogue de fonctionnalités de la solution.

Solutions connexes

Skype for Business n'a pas par défaut une solution pour l'ensemble des besoins téléphonique d'une société. Il existe des solutions tierces qui s'intègrent avec Skype. En voici quelques-unes.

ACD

Les ACD (ou Automatic Call Distribution) sont des dispositifs (logiciels ou matériels) qui permettent la gestion d'un centre d'appels. Ces centres d'appels peuvent être des accueils, des relations patron / secrétaire, un service support...

Par défaut, Skype intègre les Response Groups. Cette fonctionnalité permet de faire des groupements d'appels. Malheureusement cette fonctionnalité est limitée et ne permet pas de répondre à tous les besoins. 

J'ai pu tester deux solutions d'ACD lors de mes projets qui sont :

• CC4Skype (http://www.cc4skype.com/en/)
• Anywhere365 (https://www.workstreampeople.com/anywhere365)

 Logs et facturation

Il est possible d'activer dans Skype for Business les rapports de surveillance. Pour cela, il faut configurer le rôle SQL Reporting Services sur un serveur Back-End. Ces logs tracent l'ensemble des communications des utilisateurs (chat, partages, appels entrants, sortants...).

Bien que ces logs existent, pour faire de la facturation sur les appels sortants ils sont peu exploitables. Il y a alors deux possibilités, faire appel à une solution tierce (comme Periscope GC http://www.cvt.com.au/periscopegcskypefb ou UC Analytics http://www.mindcti.com/uc-analytics/) ou développer un rapport personnalisé dans SQL Reporting Services.

Conclusion

De nombreux éditeurs ont développés des solutions supplémentaires pour Skype for Business. Microsoft recense l'ensemble des applications tierces compatibles sur le site http://apps.skypeforbusiness.com/.

Ce billet termine mon retour d'expérience sur la téléphonie à travers Skype for Business. J'espère qu'il vous a été utile. 

Problème:

Sur Windows Server 2008 quand vous réalisez la rétrogradation d'un contrôleur de domaine à simple serveur membre, vous pouvez rencontrer une erreur de type :

"Operations which require contacting a FSMO operation master will fail until this condition is corrected"

Ce problème se produit quand la commande essaie de contacter le maître d'infrastructure et qu'elle echoue pour une des raisons suivantes:

• La ou les partitions mentionnées dans le message d'erreur ne sont plus existantes.
• Le maître d'infrastructure pour la ou les partitions mentionnées, a été rétrogradé de force ou est hors ligne (hors réseau ou éteint).

Solution:

Dans le premier cas de figure Microsoft préconise un nettoyage des métadonnées de la partition orpheline en utilisant l'outils Dsmgmt (cf: http://technet.microsoft.com/en-us/library/cc730970(ws.10).aspx ).

Dans le deuxième cas de figure il suffit de spécifier un propriétaire du rôle maître d'infrastructure qui est "En ligne", pour cela vous pouvez exécuter le script suivant à l'aide de la commande :

cscript fixfsmo.vbs DC=DomainDnsZones,DC=VotreNomDeDomaine,DC=XXX (Remplacez XXX par votre extension: fr, com, lan, biz...)

Le script:

Le script ci-dessous permet de modifier l'attribut "fSMORoleOwner" dans le domaine spécifié dans la ligne de commande.

'-------fixfsmo.vbs------------------
const ADS_NAME_INITTYPE_GC = 3
const ADS_NAME_TYPE_1779 = 1
const ADS_NAME_TYPE_CANONICAL = 2

set inArgs = WScript.Arguments

if (inArgs.Count = 1) then
    ' Assume the command line argument is the NDNC (in DN form) to use.
    NdncDN = inArgs(0)
	Else
    Wscript.StdOut.Write "usage: cscript fixfsmo.vbs NdncDN"
	End if
	
if (NdncDN <> "") then

' Convert the DN form of the NDNC into DNS dotted form.
    Set objTranslator = CreateObject("NameTranslate")
    objTranslator.Init ADS_NAME_INITTYPE_GC, ""
    objTranslator.Set ADS_NAME_TYPE_1779, NdncDN
    strDomainDNS = objTranslator.Get(ADS_NAME_TYPE_CANONICAL)
    strDomainDNS = Left(strDomainDNS, len(strDomainDNS)-1)
	
	Wscript.Echo "DNS name: " & strDomainDNS
    
	' Find a domain controller that hosts this NDNC and that is online.
    set objRootDSE = GetObject("LDAP://" & strDomainDNS & "/RootDSE")
    strDnsHostName = objRootDSE.Get("dnsHostName")
    strDsServiceName = objRootDSE.Get("dsServiceName")
    Wscript.Echo "Using DC " & strDnsHostName

    ' Get the current infrastructure fsmo.
    strInfraDN = "CN=Infrastructure," & NdncDN
    set objInfra = GetObject("LDAP://" & strInfraDN)
    Wscript.Echo "infra fsmo is " & objInfra.fsmoroleowner
	
	' If the current fsmo holder is deleted, set the fsmo holder to this domain controller.
    if (InStr(objInfra.fsmoroleowner, "\0ADEL:") > 0) then
	' Set the fsmo holder to this domain controller.
	objInfra.Put "fSMORoleOwner",  strDsServiceName
	objInfra.SetInfo
	
	' Read the fsmo holder back.
	set objInfra = GetObject("LDAP://" & strInfraDN)
	Wscript.Echo "infra fsmo changed to:" & objInfra.fsmoroleowner
	
    End if
	
End if	

Une fois le script exécuté vous devriez pouvoir rétrograder votre contrôleur de domaine, si toutefois le problème persistait il faudra passer par la console ADSI Edit.

La requête ci-dessous permet de lister tout les overrides de manière ‘clarifiés’ afin d’identifier les objets a la source de ces overrides, les paramètres concernés et les management pack sources et de destination.

Les paramètres @Startdate et @EndDate permettent de spécifier une fenêtre de temps concernant les dates de création et de dernière modification des overrides.

declare @StartDate  datetime
declare @EndDate    datetime
set @EndDate = GETDATE()
set @StartDate = DATEADD(day,-60,@EndDate)
 
SELECT DISTINCT MP.MPFriendlyName AS 'Management Pack'
, aov.ParentType AS 'Type'
,(CASE 
       WHEN AOV.OverrideType = 'RuleProperty' THEN R.RuleName 
       WHEN AOV.OverrideType = 'MonitorProperty' THEN M.MonitorName 
       WHEN AOV.OverrideType = 'RuleConfiguration' THEN R.RuleName 
       WHEN AOV.OverrideType = 'MonitorConfiguration' THEN M.MonitorName 
 END) AS 'NameType',
mt.DisplayName AS ContextDisplayName
, aov.OverrideableParameterName
, aov.Value,
(CASE Enforced 
       WHEN '0' THEN 'False' 
       WHEN '1' THEN 'True' 
  END) AS 'Enforced'
  , aov.LastModified
  , aov.TimeAdded
  ,(CASE 
  WHEN AOV.OverrideType = 'RuleProperty' THEN 
             (CASE R.RuleEnabled 
             WHEN '0' THEN 'False' 
             WHEN '2' THEN 'True' 
             WHEN '3' THEN 'True' 
             WHEN '4' THEN 'True' 
             END)
 
  WHEN AOV.OverrideType = 'MonitorProperty' THEN 
             (CASE M.MonitorEnabled 
             WHEN '0' THEN 'False' 
             WHEN '2' THEN 'True' 
             WHEN '3' THEN 'True' 
             WHEN '4' THEN 'True' 
             END)
 
  WHEN AOV.OverrideType = 'RuleConfiguration' THEN 
             (CASE R.RuleEnabled 
             WHEN '0' THEN 'False' 
             WHEN '2' THEN 'True' 
             WHEN '3' THEN 'True' 
             WHEN '4' THEN 'True' 
             END)
             
  WHEN AOV.OverrideType = 'MonitorConfiguration' THEN 
             (CASE M.MonitorEnabled 
             WHEN '0' THEN 'False' 
             WHEN '2' THEN 'True' 
             WHEN '3' THEN 'True'
             WHEN '4' THEN 'True' 
             END) 
END) AS 'Enable_by_default', MPSTORE.MPFriendlyName AS 'MP Stored'
 
FROM AllOverrideView AS aov 
LEFT OUTER JOIN Rules AS R WITH (nolock) ON aov.TargetId = R.RuleId AND (aov.OverrideType = 'RuleProperty' OR aov.OverrideType = 'RuleConfiguration') 
LEFT OUTER JOIN Monitor AS M WITH (nolock) ON aov.TargetId = M.MonitorId AND (aov.OverrideType = 'MonitorProperty' OR aov.OverrideType = 'MonitorConfiguration') 
LEFT OUTER JOIN  ManagementPack AS MP WITH (nolock) ON (CASE 
                                                                                              WHEN AOV.OverrideType = 'RuleProperty' THEN R.ManagementPackId 
                                                                                              WHEN AOV.OverrideType = 'RuleConfiguration' THEN R.ManagementPackId
                                                                                              WHEN AOV.OverrideType = 'MonitorProperty' THEN M.ManagementPackId 
                                                                                              WHEN AOV.OverrideType = 'MonitorConfiguration' THEN M.ManagementPackId
                                                                                              END) = MP.ManagementPackId 
INNER JOIN ManagementPack AS MPSTORE WITH (nolock) ON MPSTORE.ManagementPackId = aov.ManagementPackId 
LEFT OUTER JOIN ManagedTypeView AS mt WITH (nolock) ON mt.Id = aov.ContextId 
LEFT OUTER JOIN ManagedTypeView AS mtv WITH (nolock) ON mtv.Id = aov.ContextObjectId
 
WHERE (MP.MPFriendlyName IS NOT NULL) 
AND (aov.LastModified BETWEEN @StartDate AND @EndDate) 
OR (MP.MPFriendlyName IS NOT NULL) 
AND (aov.TimeAdded BETWEEN @StartDate AND @EndDate)
 
ORDER BY aov.TimeAdded DESC

Contexte

Lors du déploiement d'un nouveau serveur WSUS, des serveurs ou postes de travail apparaissent et disparaissent de la console sans raison logique au premier abord.

Explication

Si les clients apparaissent et disparaissent de la console par intermittence, le soucis vient probablement du SUSClientID.

Cette situation peut arriver quand un serveur est cloné et que les clés de registre liées au SUSclientID ne sont pas modifiées, ou dans le cas des postes de travail, le problème peut se poser si les postes sont déployés via une image système mal configurée (pas de sysprep). 

Résolution

La solution a ce problème est relativement simple une fois que les différents clients concernés ont été identifiés.

Sur chaque client concerné, supprimez clés de registre suivantes:

• SusClientId
• SusClientIDValidation

Ces clés sont situées à la racine de la ruche: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate

Ouvrez ensuite une invite de commande en mode administrateur et exécutez les commandes suivantes:

• wuauclt.exe /resetauthorization / detectnow
• wuauclt.exe /detectnow

Il faut refaire ces actions sur chaque poste client/serveur concerné.

Les clients devraient ensuite remonter sans soucis dans la console WSUS.

Dans le cadre d'une migration depuis des contrôleurs de domaines Windows Server 2003 vers des contrôleurs de domaine en Windows Server 2016 après avoir effectué l'extension du schéma ainsi que le forestprep et le domainprep avec succès, le gpprep échoue avec l'erreur suivante:

Gpprep operation 3 failed.

Upgrade of domain Group Policy Objects failed.

Adprep encountered a Win32 error.
Error code: 0x41 Error message: Network access is denied.

Le cas initial dans lequel cette erreur a été rencontrée est le suivant:

• Extension du schéma, forestprep, domainprep, gpprep exécutés depuis un serveur Windows Server 2016, qui n'est pas contrôleur de domaine et qui est en WORKGROUP et un compte ayant les droits suffisants. En effet l'upgrade de schéma depuis un serveur en workgroup est possible en spécifiant les crédentials et les foret/domaine en paramètres sur les différentes commandes.

L'upgrade a ensuite été de nouveau tentée dans le cadre suivant:

• Extension du schéma, forestprep, domainprep, gpprep exécutés depuis un serveur Windows Server 2016, qui n'est pas contrôleur de domaine et qui est membre du domaine.

Résultat: Même erreur que dans le cas initial.

Enfin, l'upgrade a été lancée dans l'environnement suivant:

• Extension du schéma, forestprep, domainprep, gpprep exécutés depuis un serveur Windows Server 2016, qui a été promu contrôleur de domaine au préalable et donc membre du domaine.

Résultat: Gpprep réussi.

Le fait que le GPPREP échoue, n'est pas un point bloquant pour le passage vers AD 2016, cependant il pourrait y avoir des répercussions sur les différentes GPO existantes si les modifications réalisées par le GPPREP ne sont pas appliquées correctement.

Il est également possible de faire l'ensemble des opérations depuis un serveur 2016 qui n'est pas encore contrôleur de domaine, et si le gpprep échoue, le relancer plus tard, une fois le serveur promu en tant que contrôleur de domaine.