Problème:

Les clients Outlook n'arrivent plus à accéder à la GAL sur Exchange, et donc les utilisateurs sont dans l'incapacité d'ajouter des salles de réunions ou de rechercher contacts qui ne sont pas dans leur cache Outlook. Le client se fige et le message d'erreur suivant apparait après quelques dizaines de secondes:

Troubleshooting:

• Vérification des journaux d'événements .
• Vérification de la réplication AD et Exchange.
• Régénération de l'OAB et MaJ de la GAL. 
• Déplacement de la boite mail contenant l'OAB vers un autre serveur.
• Entrée dans le fichier host pour pointer directement sur le serveur hébergeant l'OAB.
• Test d'accès sur l'URL EWS et l'URL OAB.
• Vérification des logs IIS.

Solution:

Des erreurs 401 étaient retournées depuis le serveur dans les logs IIS. Pour résoudre cette erreur il a fallu redémarrer les services IIS, puis les services "RPC Client Access" et "MS Exchange Throttling", puis de nouveau redémarrer les services IIS.

Problème:

Après une installation d'Exchange avec un chemin d'installation différent de celui par défaut, certains compteurs de performance remontent en erreur dans les journaux d'événements.

Solution:

Reconstruire les compteurs de performance à l'aide du script suivant:

Add-Pssnapin Microsoft.Exchange.Management.PowerShell.Setup

$Fichiers =get-childitem "E:\Exchange Server\Setup\Perf\" *.xml |where-object {!($_.psiscontainer)}

foreach ($fichier in $fichiers) {

Remove-perfcounters -Definitionfilename $file.fullname

}
foreach ($fichier in $fichiers) {

New-perfcounters -Definitionfilename $file.fullname

}

Problème:

Impossible de requêter les membres d'un groupe dynamique Exchange ayant un paramètre de filtrage sur le champ "CountryOrRegion".

L'erreur spécifiée est générique et indique que le filtre OPATH ou LDAP est invalide:

"La chaîne de filtre de prévisualisation du destinataire $VotreFiltre n'est ni un filtre OPath valide ni un filtre LDAP valide. Utilisez le paramètre -RecipientPreviewFilter avec une chaîne de filtre OPath valide ou une chaîne de filtre LDAP valide."

Cause:

Une des raisons possible à ce message d'erreur est que la valeur du champ CountryOrRegion ait été déclarée depuis une console Powershell en français (ou toute langue autre que l'anglais). En effet la console powershell interprète et traduit directement la valeur spécifiée pour l'attribut CountryOrRegion.

Par exemple, si vous spécifiez la valeur "CountryOrRegion -eq Germany" ou "CountryOrRegion -eq DE" et que votre console powershell est en français, la valeur retenue et transmise dans le filtre OPATH sera "CountryOrRegion -eq Allemagne".

Ceci est problématique car les serveurs Exchange installés en anglais seront incapables de traduire cette valeur et vous ne pourrez pas interagir avec cette liste de distribution dynamique pour la partie modification et récupération des membres, la liste en elle-même devrait normalement être fonctionnelle. 

Autre raison possible, la valeur n'est pas renseignée correctement.

Les valeurs doivent correspondre à la norme ISO 3166-1 de l'appellation des pays.

https://fr.wikipedia.org/wiki/ISO_3166-1

Solution:

Actuellement, ce problème est considéré comme un fonctionnement standard du produit, pour corriger les listes de distributions dynamiques en erreur, il vous faudra les recréer depuis une console en anglais.

Dans un environnement hybride, avec des utilisateurs synchronisés depuis l'Active Directory vers O365, il n'est actuellement pas possible de changer l'UPN directement par le portail d'administration O365.

Cependant avec les commandes Powershell suivante, il est possible de modifier l'UPN directement dans O365:

Il faut passer par l'adresse technique pour changer l'UPN de l'utilisateur d'un domaine à un autre, il faut cependant que l'UPN final soit égal à la valeur présente dans l'Active Directory Onpremise.

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.

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. 

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:

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 :

Exécuter la commande suivante :

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

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.

AppLocker est une fonctionnalité permettant de spécifier les utilisateurs ou groupes de votre organisation pouvant exécuter des applications particulières en fonction de l’identité unique des fichiers. Si vous utilisez AppLocker, vous pouvez créer des règles pour autoriser ou refuser l’exécution d’applications.

AppLocker peut, par exemple, être utilisé dans le cadre d’un déploiement d’une infrastructure PKI d’entreprise à deux niveaux afin de sécuriser l’autorité de certification racine.

Cependant, sur la version Windows Server 2016 et  il n’est actuellement pas possible de programmer le démarrage automatique du service AppIDSvc via l’interface graphique, ni même par GPO comme indiqué par Microsoft.

L’erreur suivante apparait quand on essaye d’appliquer le paramètre “Démarrage automatique” :

Afin que le service AppIDSvc se lance de manière automatique à chaque démarrage il faut modifier la clé de registre suivante:

Valeur: Start=2

Clé: HKLM\SYSTEM\CurrentControlSet\Services\AppIDSvc

Une fois la clé modifiée, redémarrez le service.

Le service est maintenant en démarrage automatique: