PI Services

Le blog des collaborateurs de PI Services

MECM (SCCM) : Script de maintenance WSUS pour changer wsyncmgr purge des mises à jour expirées de 7 jours à 0 jour

Microsoft Endpoint Configuration Manager est capable de supprimer automatiquement le contenu des mises à jour logicielles des points de distribution lorsque ce contenu est lié à des mises à jour expirées. Ce processus permet de gérer l'espace disque sur vos points de distribution en supprimant tout contenu dont vous n'avez plus besoin.

Si celles-ci ne se trouvent dans aucun groupe de mises à jour logicielles, ConfigMgr purgera automatiquement les mises à jour expirées après 7 jours. Vous pouvez modifier le nettoyage à 0 jour si vous souhaitez que les composants wsyncmgr suppriment immédiatement les mises à jour expirées (en supposant qu'ils ne soient pas dans un groupe de mises à jour logicielles). On appelle ce nombre de jours, âge de nettoyage des mises à jour (Updates Cleanup Age)

Ci-dessous un script VBS qui permet de changer la valeur de l'âge de nettoyage des mises à jour sur votre ConfigMgr :

On Error Resume Next

'***  Define string variables for device, device Resource ID and user of interest

Class_Name = 		"SMS_SCI_Component"
Class_ItemName =	"SMS_WSUS_SYNC_MANAGER|<<<***CHANGEME***SCCMSERVERNAMEHERE>>>.YOURDOMAIN.COM"
Class_ItemType =	"Component"
Property_Name = 	"Updates Cleanup Age"
Property_SiteCode = 	"*****SCCMSITECODEHERE*****"
DesiredValue =		0

'***  Check parameters - we need the provider server name and the site code

set args=wscript.arguments

If args.Count = 2 then
	SMSProviderServer = UCASE(Wscript.Arguments(0))
	SiteCode = UCASE(Wscript.Arguments(1))
Else
	wscript.Echo "Incorrect command line arguments." & vbCrLf & "Usage: cscript /nologo ModifySCFProperty.vbs <smsproviderserver> <sitecode>" & vbCrLf & "Example: cscript /nologo ModifySCFProperty.vbs SERVER1 S01 > schedules.txt" & vbCrLf
	WScript.Quit(1)
End If


'***  Connect to the provider - report the error and terminate on failure

SMSProviderServer = "\\" + SMSProviderServer + "\"
Set ObjSvc = GetObject("winmgmts:" & "{impersonationLevel=Impersonate,authenticationLevel=Pkt}!" & SMSProviderServer & "root\sms\site_" & SiteCode)

If Err.Number <> 0 Then
	wscript.Echo "Failed to connect to provider server with code: " & Err.Number & ".  Aborting!"
	WScript.Quit(2)
End If

'***  Get the desired instance of the class

Set objInst = ObjSvc.Get(Class_Name & ".ItemName='" & Class_ItemName & "',ItemType='" & Class_ItemType & "',SiteCode='" & Property_SiteCode &"'")

If Err.Number <> 0 Then
	WScript.Echo "Failed to open desired object with error code " & Err.Number & " (" & Err.Description & ").  Aborting!"
	WScript.Quit(3)
End If

'***  Loop through the Properties until we find a match or run out

bFoundProperty = False

For Each objProp in objInst.Props
	If objProp.PropertyName = Property_Name Then
		bFoundProperty = True
		Exit For
	End If
Next

If bFoundProperty = False Then
	WScript.Echo "Desired object was found but property was not found.  Exiting without making any changes."
	WScript.Quit(4)
End If	

'***  Property found so check to see if existing value matches desired, changing it as appropriate

If objProp.Value = DesiredValue Then
	WScript.Echo "Property '" & Property_Name & "' found with desired value '" & DesiredValue & "'.  Not making any changes."
	WScript.Quit(0)
Else
	OriginalValue = objProp.Value
	objProp.Value = DesiredValue
	objProp.Put_
	objInst.Put_

	If Err.Number <> 0 Then
		wscript.Echo "Failed to save the desired change with code: " & Err.Number & ".  Aborting!"
		WScript.Quit(5)
	Else
		WScript.Echo "Property '" & Property_Name & "' successfully changed from '" & OriginalValue & "' to '" & DesiredValue & "'."
	End If
End If

 

Sources:

https://docs.microsoft.com/en-us/troubleshoot/mem/configmgr/software-update-maintenance

https://www.reddit.com/r/SCCM/comments/ab7v6f/software_updates_remove_old_ones/

https://youtu.be/wqBaTp855sk?t=1765

https://setupconfigmgr.com/wp-content/uploads/2018/06/Adjust-WSync_UpdateCleanupAge.zip

Powershell : Comparer une date manuellement saisie avec un format spécifique à la date du last logon d'un utilisateur dans Active Directory

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.

MEM / Intune : Configurer Google Chrome à l'aide de l'ingestion ADMX

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 puis Périphériques puis 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

Active Directory – Comment afficher la clé de récupération Bitlocker

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...
  • Ajoutez des groupes qui doivent afficher la clé de récupération

  • 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/ 

MECM (SCCM) : Code d'erreur de séquences de tâches 0X80091007

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.

MECM (SCCM) : Remettre à zéro l'indicateur d'installation

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

 

ADMT : Contrôleur de domaine à utiliser lors d'une migration ordinateur

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.