PI Services

Le blog des collaborateurs de PI Services

Power BI - Dax - Exemple d'utilisation de OR (II) dans un Filtre

Problématique: Nous voulons a travers une requete Dax compter un nombre de machines possedant une application 'MyApp' dans une table nommée MY_HOSTS_AND_APPS

Mais une partie des machines n'a pas cette info renseignée dans la colonne [AppName]. Cette info est inscrite sous la forme d'un texte libre dans une autre colonne [HostUsage]

Il est possible dans ce cas d'utiliser un OR (preferer l'alias '||') dans la clause FILTER.

On compte donc (DISTINCTCOUNT), les HostName où [AppName] est égale a "MyApp" ou bien (||) la chaine "MyApp" est presente dans [HostUsage]  (SEARCH)

 

WithMyApp = 
VAR Result = CALCULATE(
    DISTINCTCOUNT(MY_HOSTS_AND_APPS[HostName]),
        FILTER(MY_HOSTS_AND_APPS,MY_HOSTS_AND_APPS[AppName]="MyApp"
        ||
        SEARCH("MyApp",MY_HOSTS_AND_APPS[HostUsage],1,0)
        )               
)
RETURN(
    IF (Result=BLANK(),0,Result))

 

 

Active Directory - Forcer la restauration DFSR sysvol d'un contrôleur de domaine

SYSVOL est un partage de fichier créé par défaut et partagé entre chaque contrôleur de domaines (DC) dans un Active Directory (AD). DFSR est le mécanisme en charge de la réplication du contenu du SYSVOL entre chaque DC. La santé de la réplication DFSR sysvol est essentielle, car certains services de l'AD en dépendent pour leur fonctionnement, tel que les GPO.

Prérequis pour identifier les problèmes de réplication DFSR sysvol et forcer la restauration

  • Avoir un compte Domain Admin
  • Avoir accès au DC qui a des problèmes de réplications
  • Avoir accès à la commande Dfsrdiag depuis le DC qui a des problèmes de réplications, si la commande n'est pas accessible, elle peut être installée depuis Server Manager > Add Roles and Features > Features > Role Administration Tools > File Services Tools > DFS Management Tools

Identifier les problèmes de réplication DFSR sysvol

Pour les exemples qui vont suivre, le DC2 présente des problèmes de réplications DFSR sysvol depuis le DC1 qui est sain. 

Plusieurs éléments qui ne nécessitent pas d'investiguer des logs peuvent alerter d'un problème de réplication DFSR sysvol :

  • Lorsqu'une GPO créée sur le DC1 n'est pas accessible depuis le DC2, exemple de message d'erreur dans la console Group Policy Management : The system cannot find the file specified.
  • Lorsqu'un fichier est créé dans le SYSVOL du DC1 \\DC1.domain.intern\SYSVOL\domain.intern et qu'il n'est pas répliqué dans le SYSVOL du DC2 \\DC2.domain.intern\SYSVOL\domain.intern
  • Lorsque le nombre de GPO du DC1 \\DC1.domain.intern\SYSVOL\domain.intern\Policies est différent du nombre de GPO du DC2 \\DC2.domain.intern\SYSVOL\domain.intern\Policies

Il est possible d'utiliser la console DFS Management pour faire des tests de réplication, mais ceux-ci ne sont pas assez granulaires.

Depuis le DC qui a des problèmes de réplications, dans une invite de commande PowerShell, la commande Dfsrdiag est utilisée pour avoir un état des lieux du statut des objets en attente de réplication.

PS C:\Windows\system32> Dfsrdiag replicationstate
Summary

  Active inbound connections: 0
  Updates received: 0

  Active outbound connections: 0
  Updates sent out: 0

Operation Succeeded

 

Le résultat de la commande précédente montre une réplication saine. Lorsque des objets sont en attente de réplication, la liste des objets non répliqués s'affiche.
La valeur de Sending member indique le DC (par exemple DC1) depuis lequel le DC actuel (par exemple DC2) essaye de répliquer les objets du SYSVOL.

Le paramètre syncnow de la commande Dfsrdiag peut être utilisé pour tenter de forcer la réplication des objets en attente.

 

Dfsrdiag syncnow /partner:DC1.domain.intern /time:5 /RGName:"Domain System Volume"

#synnow permet de forcer la réplication depuis le DC spécifié après le paramètre /partner. Le Sending member précédent peut être utilisé.

#/time est la durée en minutes pendant laquelle la réplication est forcée. 5 minutes sont choisies, car c'est suffisant pour répliquer une centaine d'objets si la réplication fonctionne.

#/RGName est le nom du partage DFS, pour sysvol il s'agit de Domain System Volume

Suite à cette commande, il faut revérifier le statut de la réplication avec la commande Dfsrdiag replicationstate.

Il est possible de tenter la réplication depuis un partenaire différent ou de laisser plus de temps à la réplication.
Si le nombre d'objets en attente de synchronisation ne varie pas, il faut procéder à une restauration du DFSR sysvol.

 

Forcer la restauration DFSR sysvol d'un contrôleur de domaine

La restauration du DFSR sysvol consiste à faire une synchronisation non authoritative depuis un DC sain. C'est-à-dire que le contenu SYSVOL du DC2 qui a des problèmes de synchronisation sera écrasé par le contenu du SYSVOL du DC1. Les méthodes utilisées précédemment : le fonctionnement par défaut de DFSR et la commande dfsrdiag syncnow tentent de faire des synchronisation avec gestion des conflits, mais certains conflits de versions ne peuvent être résolus par les algorithmes internes.

1. Se connecter au DC2 qui a des problèmes de réplications

2. Ouvrir la console ADSI Edit, faire un clique droit sur ADSI Edit et cliquer sur Connect to..

3. Dans Connection Point choisir Select a well known Naming Context puis choisir Default naming context, dans Computer choisir Select or type a domain or server puis entrer le nom du DC qui a des problèmes de réplication puis cliquer sur OK

4. Déplier les dossiers Default naming context > <Domain> > OU = Domain Controllers > CN=<Nom du DC qui a des problèmes de réplications> > CN =DFSR-LocalSettings > CN = Domain System Volume > faire un clic droit sur CN = SYSVOL Subscription > Properties

5. Dans l'onglet Attribute Editor chercher l'attribut msDFSR-Enabled, faire un clic droit sur cet attribut et changer la valeur de True à False. Cette action à permis de désactiver la réplication DFSR sysvol pour le DC2

6. Depuis le DC2 ouvrir une console PowerShell et entrer la commande

repadmin /syncall /AdP

Cette commande permet de forcer la synchronisation des AD du DC2

7. Depuis le PowerShell du DC2 entrer la commande

Dfsrdiag PollAD

Cette commande permet de récupérer la configuration DFSR sans attendre qu'une réplication AD s'exécute.

8. Il est possible de vérifier que la réplication DFSR a bien été arrêté en consultant l'Event Viewer du DC2 et notamment l'Event ID 4114 dans Applications and Services Logs > DFS Replication

9. Réactiver la synchronisation DFSR sysvol sur le DC2 en suivant les étapes 1 à 5. Cette fois passer la valeur de msDFSR-Enabled de False a True

10. Forcer la réplication AD et DfsrDiag depuis le DC2 avec les commandes des étapes 6 et 7

11. Vérifier le statut de la synchronisation non authoritative DFSR sysvol du DC2 en ouvrant l'Event Viewer depuis le DC2, depuis le dossier Applications and Services Logs > DFS Replication > consulter les logs et notamment la présence de l'Event ID 4614

12. Depuis le DC2 dans une console PowerShell, utiliser la commande Dfsrdiag replicationstate pour vérifier s'il existe toujours des objets non répliqués

13. Faire un test de réplication SYSVOL DFSR en crééant un fichier sur le DC1 (sain) \\DC1.domain.intern\SYSVOL\domain.intern puis se connecter sur le SYSVOL du DC2 (réparé) \\DC2.domain.intern\SYSVOL\domain.intern et vérifier que le fichier est présent

 

Pour aller plus loin

Documentation officielle Microsoft How to force authoritative and non-authoritative synchronization for DFSR-replicated sysvol replication

[Powershell] - Gérer la modération des listes de distribution dans un environnement en Split Model Permission

Sur le même principe que l'article précédent "autoriser une liste d'utilisateur à envoyer des email à une liste de distribution" voici la fonction pour gérer la "Modération"

Powershell

Function Allow-ToModeratedBy {
    param (
    [Parameter(Mandatory)][String]$GroupName,
    [Parameter(Mandatory)][String[]]$SamAccountName
    )

    Try {
        Get-ADGroup $GroupName -ErrorAction Stop
        foreach ($Sam in $SamAccountName) {
            Try {
                $CurrentUser = Get-ADUser $Sam -ErrorAction Stop
                Try {
                    Set-ADGroup -Identity $GroupName -Add @{msExchModeratedByLink=@($CurrentUser.DistinguishedName)} -ErrorAction Stop
                }
                Catch {
                    Write-Warning $($_)
                    }
            }
            Catch {
                Write-Warning $($_)
            }
        }
    }
    Catch {
        Write-Host "Group Not found sorry" -ForegroundColor Yellow
    }
}

 

Intune : Supprimer l'icône et l'application de Teams Chat intégré à Windows 11

Pour supprimer l'icône et l'application de Teams Chat intégré à Windows 11 sur les appareils gérés par Intune, nous avons décidé de créer des packages de script dans Intune Proactive remediations, cela nous permettra d'exécuter des scripts de détection et de correction en utilisant le compte de l'utilisateur connecté, ce qui est un prérequis.

En outre, cette méthode offre la possibilité de filtrer uniquement les appareils Windows 11 dans les affectations, ce qui n'est pas disponible dans les scripts Intune.

Ci-dessous les packages de scripts de "Proactive remediations" MEM Intune que nous avons créé pour supprimer l'icône et l'application de Teams Chat (built-in) :

1. Package de script de suppression de l'icône Chat

1.1. Contenu du script de Détection

#Script detects the new Microsoft Teams consumer app Chat Icon on Windows 11.
$RegValue = Get-ItemProperty -path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced' -name "TaskbarMn" | Select TaskbarMn
if ($RegValue.TaskbarMn -eq "0") {
       Write-Host "Chat Icon not found"
       exit 0
} Else {
       Write-Host "Chat Icon found"
       Exit 1
}

1.2. Contenu du script de Remédiation

#Script removes the new Microsoft Teams consumer app Chat Icon on Windows 11.
#Icon is removed because this app can only be used with personal Microsoft accounts
try{
    Set-ItemProperty -path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced' -name "TaskbarMn" -value "00000000"
       Write-Host "Microsoft Teams Chat Icon successfully removed"
}
catch{
    Write-Error "Error removing Chat Icon"
}

2. Package de script de suppression de l'application MS Teams

2.1. Contenu du script de Détection

#Script detects the new Microsoft Teams consumer app on Windows 11.
if ($null -eq (Get-AppxPackage -Name MicrosoftTeams)) {
       Write-Host "Microsoft Teams client not found"
       exit 0
} Else {
       Write-Host "Microsoft Teams client found"
       Exit 1
}

2.2. Contenu du script de Remédiation

#Script removes the new Microsoft Teams consumer app on Windows 11.
#App is removed because this app can only be used with personal Microsoft accounts 
try{
    Get-AppxPackage -Name MicrosoftTeams | Remove-AppxPackage -ErrorAction stop
    Write-Host "Microsoft Teams app successfully removed"
}
catch{
    Write-Error "Error removing Microsoft Teams app"
}

Une fois créés, ces packages de scripts Proactive remediations, peuvent être déployés sur le groupe d'appareils Windows 11.

MECM : Vérifier et corriger l'état du contenu sur un point de distribution

Scénario : 

Nous avons constaté qu'un package est bloqué à 0% en téléchargement dans le centre logiciel.

Depuis la console MECM, nous avons vérifié les boundaries, tout est correctement configuré.

Ensuite nous avons vérifié l'état de distribution du package sur le point de distribution, le package est affiché distribué avec succès.

Pour s'assurer de la bonne distribution du package, nous nous sommes connecté au serveur avec le rôle point de distribution et nous avons constaté qu'il manque le fichier avec le PackageID.ini sous SCCMContentLib\PkgLib.

Nous avons décidé de vérifier l'état de distribution avec l'outil Content Library Explorer :

--> L'état de notre package est PENDING, c'est à dire sa distribution n'a pas pu aboutir.

--> Ce phénomène peut arriver dans le cas où le package a été supprimé mais n'a pas été correctement nettoyé du WMI du point de distribution, mais dans notre cas le package existe toujours et n'a pas été supprimé.

Après vérification, le chemin des sources du package a été modifié sur le serveur qui les héberge. Cette modification a été la cause de l'état PENDING de notre package.

Résolution :

Lorsqu'on change le chemin des sources d'un package MECM (exemple : de "D:\sources\VLC" à "D:\sources\VLC\v3.1"), il faut aussi mettre à jour le chemin vers le contenu dans l'onglet "Content" (cas d'une application) ou "Data Source" (cas d'un package) du package depuis la console.

Est-ce suffisant ? La réponse est NON !

Il faut également lancer l'action Update Content (depuis l'onglet Deployment Types) si c'est une application :

Ou l'action Update Distribution Points si c'est un package :