PI Services

Dans le cadre de l'automatisation, il arrive de recevoir une demande pour développer un script PowerShell pour le nettoyage ou la gestion de l'obsolescence des utilisateurs dans l'Active Directory.

Dans le script, vous aurez peut être besoin de comparer la date du last logon utilisateur dans l'Active Directory avec une date manuellement saisie (variable du script) avec un format spécifique.

Ci-dessous un exemple de PowerShell pour comparer une date donnée avec une date de last logon utilisateur dans Active Directory :

# Import Active Directory Module
Import-Module ActiveDirectory
 
#Set a fixed date for comparison
$Fixed_Date = "13/11/2021"
 
#Convert the fixed date from a string to a compatible specific format
$Fixed_Date_Convert = [datetime]::parseexact($Fixed_Date, 'dd/MM/yyyy', $null)  
 
#Get AD user last logon date in dd/MM/yyyy format
$ADUser = get-aduser "jdoe" -Properties lastlogondate | select @{Name=”ModifiedLastLogonDate”;Expression={$_.LastLogonDate.ToString(“dd/MM/yyyy”)}}
 
#Convert AD last logon date to a specific format to be compared with the chosen date above
$ADdate = [datetime]::parseexact($ADUser.ModifiedLastLogonDate, 'dd/MM/yyyy', $null)
 
if($ADdate -le $Fixed_Date_Convert)
    {
        echo "Active directory last logon date is inferior to the fixed date"
        }
    else
    {
        echo "Active directory last logon date is superior to the fixed date"
        }

Conclusion:

La méthode [datetime]::parseexact(dateString, format, provider) Convertit la représentation sous forme de chaîne spécifiée d'une date et d'une heure en son équivalent DateTime.

La configuration des paramètres de stratégie de Microsoft Edge dans Microsoft Intune peut être gérée par le profil de modèles d'administration déjà intégré.

Si vous souhaitez gérer les paramètres de stratégie de Google Chrome dans Microsoft Intune, ils ne sont actuellement pas disponible dans les modèle d'administration. Dans ce cas, la solution est de configurer Google Chrome avec des paramètres personnalisés pour les appareils Windows 10 et versions ultérieures dans Intune.

La configuration se passe en deux étapes :

1. Ingérer le fichier ADMX Google Chrome dans Intune

Pour ingérer le fichier ADMX, procédez comme suit :

- Téléchargez les modèles ADMX Chrome

- Connectez-vous au portail Microsoft Azure

- Accédez à Intune  Périphériques  Profils de configuration

- Dans la barre de commandes supérieure, sélectionnez + Créer profil

Sélectionnez un profil personnalisé (Custom) ensuite cliquez sur créer et choisissez un nom dans le menu suivant.

Dans la configuration des paramètres OMA-URI, saisissez le texte suivant :

• Nom
  Google Chrome ADMX ingestion
• Description
  Saisir une description (facultatif)
• OMA-URI
  ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx
• Type de données
  Chaîne (à sélectionner dans la liste déroulante)

Une fois que vous avez sélectionné Chaîne, un champ de texte intitulé Valeur s'affiche en bas. Vous allez trouver le contenu de ce champ texte dans le fichier chrome.admx qui se trouve dans le fichier .zip que vous avez déjà téléchargé (modèles ADMX Chrome) sous le chemin suivant : Configuration/admx/chrome.admx.

Cliquez sur Save.

2. Définir une stratégie à l'aide d'un OMA-URI personnalisé dans Intune

Sur le même profil, on peut ajouter des OMA-URI personnalisé pour définir des stratégies de Google Chrome.

Pour ajouter des paramètres de stratégie Google Chrome, vous devez ouvrir le profil déjà créé pour ingérer l'ADMX, ensuite cliquer sur Propriétés, puis sur Modifier les Paramètres de configuration.

Dans cet exemple, nous allons ajouter un paramètre OMA-URI personnalisé afin d'autoriser les Popup dans Chrome pour "piservices.fr".

Dans le menu suivant, cliquez sur Ajouter

Dans le menu suivant, indiquez les informations suivantes :

• Nom
  CHROME Allow Popup
• Description
  Saisir une description (facultatif)
• OMA-URI
  ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~ContentSettings/PopupsAllowedForUrls
• Type de données
  Chaîne (à sélectionner dans la liste déroulante)
• Valeur

  <enabled/>

  <data id="PopupsAllowedForUrlsDesc" value="1&#xF000;[*.]piservices.fr"/>a

Cliquez sur Save.

Sources :

Gérer le navigateur Chrome avec Microsoft Intune - Aide Google Chrome Enterprise

Configurer Microsoft Edge à l’aide de Gestion des périphériques mobiles | Microsoft Docs

Lorsque Bitlocker est activé sur le poste de travail / ordinateur portable de votre entreprise, vous devez disposer d’une solution pour obtenir la clé de récupération du disque dur. Dans certains cas, Bitlocker peut demander à l’utilisateur la clé de récupération s’il détecte un comportement spécifique tel que des modifications de partition.

Si vous n'avez pas la solution MBAM (Microsoft BitLocker Administration and Monitoring) en place pour centraliser la gestion de Bitlocker, la solution la plus simple consiste à utiliser soit la console Utilisateurs et ordinateurs Active Directory soit la console de modification ADSI.

Cela ne peut être possible que si vous définissez dans la GPO de stocker la clé de récupération dans Active Directory.

Utilisation de la console Utilisateurs et ordinateurs Active Directory:

Pour utiliser la console Utilisateurs et ordinateurs Active Directory, il faut installer un plug-in pour afficher les informations de clé de récupération Bitlocker. Il est intégré dans les fonctionnalités depuis Windows Server 2008.

Après l’installation, fermez et ouvrez à nouveau Utilisateurs et ordinateurs Active Directory.

Un nouvel onglet est maintenant disponible sur l’objet ordinateur : Bitlocker Recovery

Utilisation de la console de modification ADSI:

Pour afficher la clé de récupération Bitlocker depuis la console de modification ADSI, il suffit d'ouvrir cette dernière avec un compte qui a les droits et chercher le nom d'ordinateur sous l'unité d'organisation cible.

Cliquez sur le nom d'ordinateur concerné, puis double-cliquez sur le dernier objet du volet droit  

Ensuite, cherchez l'attribut msFVE-RecoveryPassword pour avoir la valeur de la clé de récupération Bitlocker

Droits de délégation nécessaire pour afficher la clé de récupération Bitlocker:

Pour visualiser la clé de récupération Bitlocker, il faut avoir des droits administrateur de domaine. Sinon si vous souhaitez donner les droits nécessaires pour afficher ces informations à quelqu'un qui n'est pas administrateur de domaine, il faut lui déléguer certains droits sur l'unité d'organisation ciblée.

• Faites un clic droit sur l’unité d’organisation ciblée et sélectionnez Delegate Control...

• Sélectionnez Create a custom task to delegate

• Choisissez Only the following objects in the folder: et cochez "msFVE-RecoveryInformation objects"

• Donnez le contrôle total sur cet objet

Sources:

https://www.manishbangia.com/how-to-get-bitlocker-recovery-password-from-active-directory/#jp-carousel-3904 
http://www.alexandreviot.net/2015/06/10/active-directory-how-to-display-bitlocker-recovery-key/ 

Lors du déploiement du Master sur un ordinateur portable, la séquence de tâches SCCM a échoué avec le code d’erreur 0X80091007.

Cette séquence de tâches fonctionnait bien, mais cette erreur s’est produite sans aucune explication.

En regardant le fichier log "smsts.log" de la machine en question, il y a une ligne qui dit clairement que la séquence de tâche a échoué lors de l’installation de Microsoft Office 2013. Cependant, le package Office n'était pas corrompu. Ce problème avait donc une autre solution que la recréation du package.

Après une investigation plus approfondie du fichier log, il a révélé les erreurs ci-dessous :

Failed to run the action: Error in the task sequence.
Task Sequence Error Running: Install Microsoft Office 2013 Professional.
Install Microsoft Office 2013 Professional has failed with the error code (0x80091007).
The hash value is not correct. (Error: 80091007; Source: Windows)
For more information, please contact your system administrator or help-desk operator.

DownloadContentAndVerifyHash() failed. 80091007

En cherchant sur internet, le code d'erreur 0X80091007 se traduit par Hash Mismatch (The hash value is not correct).

Conclusion:

Il n’y avait pas de solution unique à cette erreur. Si vous rencontrez également le code d’erreur de séquence de tâches SCCM 0X80091007, essayez les solutions ci-dessous :

• Supprimez le package du point de distribution et re-distribuez-le. C’est juste pour être sûr qu’un package valide est disponible avec le point de distribution
• Vérifiez si la mémoire RAM installée est défaillante. Cette solution semble être la plus stupide. Mais, le remplacement de barrette RAM a résolu ce problème dans notre scénario.
• Certaines personnes ont résolu l’erreur d’incompatibilité de hachage en désactivant la réplication différentielle binaire et en redistribuant le package à DP.

Dans notre scénario, problème détecté :

Barrette mémoire ram amovible défaillante. Elle est la source d’un problème de vérification de hash lors du téléchargement des sources de la séquence de tâches depuis MECM (DownloadContentAndVerifyHash() failed. 80091007)

Solution :

Enlever la barrette ram amovible et la remplacer par une nouvelle.

Une des bonne pratiques SCCM est d'activer la tâche de maintenance "Remettre à zéro l'indicateur d'installation".

Cette tâche permet d'effacer les indicateurs d'installation lorsque la découverte par pulsations d'inventaire ne découvre aucun client au cours de la période de redécouverte.

L'avantage d'avoir activé cette tâche de maintenance est de garder les indicateurs d'installation des agents MECM à jour et de détecter les agents qui ne sont plus en bonne santé et les réinstaller.

Pour activer cette tâche, sur la console MECM, cliquer sur Administration > Configuration de site > Sites > Cliquer sur le site primaire puis sur Maintenance de site.

Chercher la tâche avec le nom "Remettre à zéro l'indicateur d'installation" et cliquer sur activer. il est possible également de définir la planification pour contrôler la fréquence d'exécution de la tâche.

Dans la capture d'écran ci-dessus, la tâche de maintenance a été activée pour détecter les agents qui n'ont pas contacté le site primaire MECM depuis 40 jours par pulsation d'inventaire, si c'est le cas, l'indicateur d'installation passera de "Oui" à "Non".

- Si l'agent n'existe plus, l'indicateur reste "Non" jusqu'au nettoyage des objets obsolètes

- Si l'agent existe toujours mais était déconnectée pendant plus de 40 jours, à la prochaine connexion l'indicateur passera à "Oui"

- Si l'agent existe toujours mais ne communique pas avec MECM car il n'est plus en bonne santé, il sera réinstallé puisque l'indicateur d'installation est passé à "Non" mais la machine est connectée pour recevoir un nouveau push du client

Durant une migration ordinateur avec l'outil ADMT d'un domaine source vers un domaine cible, il est possible de rencontrer l’erreur ci-dessous :

ERR3:7075 Failed to change domain affiliation, hr=80070005 Access is denied

Cette erreur sera enregistrée dans le fichier log de migration ADMT sous c:\windows\admt\logs.

Lors de la migration des objets ordinateurs avec ADMT, l'outil demande de choisir les contrôleurs de domaine source et cible à utiliser. Le choix du DC cible est très important !

Il ne faut pas choisir n'importe quel DC cible, il faut plutôt utiliser le nom du DC où la configuration ci-dessous a été faite.

Resolution de l'erreur:

Cette erreur peut être résolue par deux méthodes :

1. Activer la stratégie de groupe (GPO) suivante sur tous les contrôleurs de domaine cible (Default domain policy) :

“Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options\NetWork Access: Named Pipes that can be accessed anonymously” avec au moins les services “netlogon,lsarpc” inclus.

2. Choisir un des contrôleurs de domaine cible (qui sera utilisé lors de la migration ordinateur) et créer la clé de registre suivante : "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes" avec les valeurs "netlogon,lsarpc"

Source : https://santhoshsivarajan.wordpress.com/2010/10/30/admt-err37075-failed-to-change-domain-affiliation-access-is-denied/

Explication de l’erreur:

ADMT agents sync the computer with the target domain using anonymous connections to the LSARPC and NETLOGON named pipes on the target domain's DC.

Source : https://social.technet.microsoft.com/Forums/ie/en-US/304f25a2-cb85-4570-b616-669a5a874ba0/admt-computer-migration-failures?forum=winserverMigration

Remarque :

Le fait d'installer l'outil ADMT PES (Paswword Export Server) sur un contrôleur de domaine, la clé de registre ci-dessus sera créée automatiquement.