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))

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

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
    }
}

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.

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 :

Symptôme

Les messages reçus sont automatiquement déplacés vers le dossier Éléments supprimés en absence de règles serveur ou sur Outlook.

Cause

Ce problème se produit si vous avez sélectionné Ignorer dans un e-mail, puis qu'un message ultérieur de ce fil de discussion arrive dans votre boîte aux lettres: Si un futur message lié au message initialement ignoré arrive dans votre boîte de réception, Outlook le déplace automatiquement vers votre dossier Éléments supprimés.

Remarque : Vous pouvez savoir qu'un message est ignoré par l'état du contrôle Ignorer sur le ruban: Dans Eléments supprimés, ouvrez le mail puis Développez le menu Supprimer, si Ignorer est mis en surbrillance, comme illustré dans la figure ci-dessous, le fil de conversation de ce message est actuellement ignoré par Outlook et les messages relatifs reçus sont déplacés automatiquement dans éléments supprimés.

Résolution

 Pour résoudre ce problème, supprimez l'état "ignorer" du fil de discussion comme suit : 

1. Sélectionnez votre dossier "Éléments supprimés" puis ouvrez le message actuellement configuré pour être ignoré dans Outlook.
2. Cliquez sur Ignorer dans le groupe Supprimer de l'onglet Message du ruban. Si vous y êtes invité, cliquez sur Arrêter d'ignorer la conversation. À ce stade, le message est automatiquement déplacé depuis votre dossier Éléments supprimés vers le dossier initial, et les futurs messages de ce fil de discussion ne seront plus automatiquement supprimés.

Lorsqu'une instance est créé dans un serveur SQL, l'authentification des utilisateurs peut être configurée de 2 façons différentes :

• Windows Authentication - les comptes de la machine et/ou du domaine AD peuvent être utilisés pour se connecter avec différents niveaux de privilèges
• Mixed mode - l'authentification Windows ainsi que l'authentification SQL (accès avec des comptes locaux à l'instance) peuvent être utilisé

Lorsque Windows Authentication est choisi, le compte local à l'instance appelé sa qui est membre du groupe sysadmin est désactivé.

sa (system administrator) est un compte utilisateur par défaut local à l'instance SQL dont le mot de passe n'est pas connu

sysadmin est un groupe par défaut local à l'instance SQL dont les membres ont les permissions les plus élevées sur l'instance SQL

Dans l'éventualité ou la personne qui a créé l'instance n'est pas disponible et qu'elle n'a pas configuré ou communiqué des accès de secours, par exemple, mixed mode ou ajout d'autres IT en tant que sysadmin, les accès administrateurs à l'instance SQL semblent impossible.

Les prérequis pour récupérer les permissions sysadmin

• Être administrateur du serveur sur lequel le serveur SQL est installé
• Avoir SQL Server Managmement Studio (SSMS) installé sur le serveur
• Si l'instance concerne un environnement de production, avertir que lors de la récupération des accès, l'instance SQL sera indisponible

Récupérer les permissions sysadmin

1. Se connecter sur le serveur sur lequel le serveur SQL est installé

2. Ouvrir la console SQL Server Configuration Manager

3. Faire un clic droit sur l'instance SQL dont l'accès sysadmin doit être récupéré et cliquer sur Properties

4. Ouvrir l'onglet Startup Parameters, dans Specify a startup parameters saisir -m puis cliquer sur Add, le paramètre -m permet de mettre l'instance SQL en mode maintenance, un utilisateur qui est admin du serveur et qui se connecte à l'instance SQL via SSMS sera, dans ce mode, également sysadmin. Ce mode n'autorise qu'un seul utilisateur à se connecter à la fois.

5. Redémarrer l'instance SQL, dont l'accès sysadmin doit être récupéré, via la console SQL Server Configuration Manager en faisant un clic droit sur l'instance puis choisir Restart

6. Depuis la console SQL Server Configuration Manager, vérifier que le service SQL Server Agent n'est pas démarré, si c'est le cas l'arrêter, auquel cas il utilisera la seule connecxion disponible pour se connecter à l'instance SQL

7. Ouvrir la console SQL Server management Studio en tant qu'administrateur

8. Se connecter à l'instance SQL dont l'accès sysadmin doit être récupéré avec comme méthode d'authentification Windows Authentication

9. Dans l'arborescence de l'instance SQL, déplier le dossier Security puis faire un clic droit sur Logins et clique sur New login...

10. Dans l'onglet General, dans le champs Login name choisir le compte utilisateur ou le groupe qui sera sysadmin, choisir Windows Authentication

11. Aller dans l'onglet Server Roles et cocher sysadmin puis clique sur OK 

12. Le nouvel accès apparaît dans la liste des Login

13. Fermer SSMS

14. Dans SQL Server Configuration Manager retirer le paramètre -m de l'instance SQL dont les accès sysadmin ont été récupéré, en sélectionnant -m et en cliquant sur Remove

15. Depuis la console SQL Server Configuration Manager redémarrer l'instance SQL dont l'accès sysadmin a été récupéré

Scénario:

Nous avons besoin d'appliquer une stratégie de conformité dans Intune à un groupe d'appareils qui contient des ordinateurs sous Windows 10 et Windows 11.

La configuration doit s'appliquer uniqument sur les appareils Windows 11.

Solution:

• Créer un filtre pour les appareils Windows 11 dans Intune
• Inclure le filtre dans le déploiement

1. Pour créer un filtre, connectez-vous au Microsoft Endpoint Manager admin center et sélectionnez Tenant administration > Filters. Sélectionnez Create

2. Pour inclure le filtre dans le déploiement, sélectionnez Devices > Windows > Compliance policies. Sélectionnez la stratégie de conformité à modifier et ajoutez un filtre dans Properties > Assignments > Edit filter

Maintenant, la stratégie de conformité "Compliance policy for Windows 11" s'appliquera uniquement sur les appareils Windows 11 dans le groupe INTUNE_BYOD_POC.

Lorsque vous créez un groupe de distribution dynamique dans Exchange 2016/2013 avec le filtre "RecipientContainer", l'onglet Aperçu n'existe plus, il fallait donc passer par Exchange Powershell pour afficher les membres du groupe.

Pour afficher l'appartenance au groupe de distribution dynamique, la commande Exchange PowerShell est simple et rapide:

Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup "DynamicGroupName").RecipientFilter

Malheureusement, comme votre groupe de distribution utilise le paramètre "RecipientContainer", la commande ci-dessus ne fonctionnera pas correctement et affichera tous les destinataires quel que soit leurs unités organisationnelles.

Pour contourner le problème, utilisez plutôt les commandes suivantes:

1. Créez tout d'abord une variable qui stockera les résultats de la commande:
   $DDL = Get-DynamicDistributionGroup "DynamicGroupName" 
2. Utilisez la variable avec la commande Get-Recipient pour renvoyer les résultats requis : Get-DynamicDistributionGroup $DDL | ForEach {Get-Recipient -RecipientPreviewFilter $_.RecipientFilter -OrganizationalUnit $_.RecipientContainer} | Select DisplayName,PrimarySMTPAddress,OrganizationalUnit | Sort-Object -Property DisplayName

Description du Problème:

Lorsque vous supprimez des messages d'une boite aux lettres, les éléments supprimés sont placés dans votre propre dossier "Éléments supprimés" au lieu du dossier "Éléments supprimés" de la boîte aux lettres partagée. 

Contournement:

Pour contourner ce problème, il faut changer la destination des éléments supprimés vers le dossier Éléments supprimés du propriétaire de la boîte aux lettres à travers une modification du paramétrage du registre comme suit:

1. Quittez Outlook
2. Démarrez l’Éditeur du Registre: Appuyez sur touche de logo Windows+R pour ouvrir une boîte de dialogue Exécuter, tapez regedit.exe, puis appuyez sur OK.
3. Trouvez la sous-clé de Registre suivante :

\HKEY_CURRENT_USER\Software\Microsoft\Office<x.0>\Outlook\Options\General

Note: L’espace réservé<x.0> représente votre version d’Office (16.0 = Office 2016, Office 2019, Office LTSC 2021 ou Microsoft 365, 15.0 = Office 2013).

4. Cliquez avec le bouton droit sur la valeur DelegateWastebasketStyle, puis sélectionnez Modifier.

Si cette valeur de Registre n’est pas présente, procédez comme suit pour la créer :

1. Cliquez avec le bouton droit sur le dossier Général dans le chemin défini à l’étape 3.
2. Pointez sur Nouveau, puis sélectionnez Valeur DWORD.
3. Tapez DelegateWastebasketStyle, puis appuyez sur Entrée
4. Remplacez les données de valeur de la boîte de dialogue Modifier la valeur DWORD par l’une des valeurs suivantes :

• 8 = Stocke les éléments supprimés dans votre dossier.
• 4 = Stocke les éléments supprimés dans le dossier du propriétaire de la boîte aux lettres.

6. Fermez l’Éditeur du Registre.
7. Redémarrez Outlook.