Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

Erreur lors du gpprep lors d’une migration AD 2003 vers AD 2016

par | 23 Mar 2017 | ,

 

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.

 

Centraliser les ADMX dans le Group Policy Central Store

par | 23 Mar 2017 |

 

Dans le cadre de la gestion des GPO, il arrive de temps en temps d’avoir des temps de chargement très long lorsque que l’on tente d’accéder à certains paramètres dans la console Group Policy Management, ce problème est peut être lié à des ADMX qui ont été chargés dans la console depuis un poste client et qui ne sont pas accessibles lorsque vous ouvrez la console.

 

Afin de régler ce problème qui peut être récurrent et gênant lors de l’administration des GPOs, il est conseillé de créer une banque centrale contenant les différents fichiers ADMX.

Afin de créer le magasin Central pour les fichiers .admx et .adml (les .adml sont les fichiers de langue correspondant aux .admx), créez un dossier nommé PolicyDefinitions à l’emplacement suivant sur un contrôleur de domaine :

\\contoso.com\SYSVOL\contoso.com\policies

Après avoir copié tous les fichiers .admx et .adml, le dossier PolicyDefinitions sur le contrôleur de domaine doit contenir les fichiers .admx et un ou plusieurs dossiers contenant les fichiers spécifiques à une langue .adml.

Les fichiers étant contenu dans le SYSVOL qui est répliqué, il ne devrait plus y avoir de lenteurs liées aux .admx lors de l’ouverture de la console GPMC. 

SQL Server–Supprimer l’un des fichiers utilisé par la TempDB

par | 20 Mar 2017 | ,

Contexte

Lors de la suppression d’un des fichiers utilisé par la base TempDB, l’opération échoue avec l’erreur suivante :

Msg 5042, Level 16, State 1, Line 1
The file 'tempdev2' cannot be removed because it is not empty.

Explication

Ce comportement est provoqué par le fait que le fichier est actuellement utilisé par SQL, il faut donc vider le fichier avant de pouvoir le supprimer.

Une solution possible est le redemmarage de l’instance SQL, ce qui va regenerer la base TempDB, moyennant une coupure de service.

Résolution

Afin d’éviter toute coupure de service, il est possible d’executer le script SQL suivant pour vider puis supprimer un fichier utilisé par la TempDB :

USE [tempdb]
GO
DBCC SHRINKFILE('tempdev2', EMPTYFILE)
GO
ALTER DATABASE [tempdb] REMOVE FILE [tempdev2]
GO

Sources

https://tenbulls.co.uk/2016/01/13/problem-removing-files-from-tempdb/

Derniers articles

Catégories

Archives

Auteurs/Autrices