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

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 :

Il est possible d’activer le balisage des e-mails externes au niveau des tenants exchange Online, ce qui permet aux clients Outlook de mettre en surbrillance les messages reçus de domaines externes.

La fonctionnalité peut remplacer les implémentations personnalisées pour marquer les e-mails comme externes, généralement effectuées via des règles de transport.

Activation du tag externe dans Exchange Online

Le balisage externe est désactivé par défaut. Vous pouvez l'activer via Exchange Online PowerShell. 

Remarque : Si vous utilisez la règle de transport pour ajouter une balise [Externe] dans la ligne d'objet, désactivez la avant d'activer le balisage externe natif afin d'éviter que les e-mails soient marqués "Externe" deux fois. 

• Pour activer la balise externe, exécutez la cmdlet suivante dans un environnement Exchange Online PowerShell:

Set-ExternalInOutlook –Enabled $true1Set-ExternalInOutlook –Enabled $true

• Pour afficher les paramètres de balisage externe, vous pouvez utiliser l'applet de commande Get-ExternalInOutlook. 
• Après avoir activé cette fonctionnalité, les nouveaux e-mails externes qui arrivent sont automatiquement marqués avec "Externe". Cela n'aura aucun impact sur les e-mails existants.

Exclusion de certaines adresses e-mail ou certains domaines du tag externe

Dans certaines situations, vous ne souhaitez pas ajouter la balise "Externe" pour certains expéditeurs externes ou domaines externes. Dans ce cas, vous pouvez les exclure en ajoutant le paramètre "AllowList". 

• Pour définir plusieurs entrées et écraser toutes les entrées existantes, exécutez la commande suivante:

Set-ExternalInOutlook –AllowList "user01@contoso.com","domain.com" 

Le nombre maximum d'entrées est de 30 et la taille totale de toutes les entrées ne peut pas dépasser un kilo-octet. Sinon, les erreurs suivantes seront affichées:

Maximum AllowList count exceeded. Max 30, Current: 31.
+ CategoryInfo : WriteError: (SetExternalInOutlook:String) [Set-ExternalInOutlook], Exception
+ FullyQualifiedErrorId : [Server=MAXPR01MB2431,RequestId=7b2ab330-0de4-43cf-8cfa-8647307773b8,TimeStamp=27-04-2021 08:25:14] [FailureCategory=Cmdlet-Exception] D8D55C02,Micr
osoft.Exchange.Management.SystemConfigurationTasks.SetExternalInOutlook
+ PSComputerName : outlook.office365.com

 Maximum AllowList length exceeded. Max 1024, Current: 1129.
+ CategoryInfo : WriteError: (SetExternalInOutlook:String) [Set-ExternalInOutlook], Exception
+ FullyQualifiedErrorId : [Server=MAXPR01MB2431,RequestId=7b2ab330-0de4-43cf-8cfa-8647307773b8,TimeStamp=27-04-2021 08:25:14] [FailureCategory=Cmdlet-Exception] D8D55C02,Micr
osoft.Exchange.Management.SystemConfigurationTasks.SetExternalInOutlook
+ PSComputerName : outlook.office365.com

• Pour ajouter de nouvelles valeurs sans affecter les valeurs existantes,

 Set-ExternalInOutlook –AllowList @{Add="microsoft.com","user02@domain.com"}

•  Pour supprimer le domaine ou l'utilisateur externe de la liste autorisée, vous pouvez utiliser l'applet de commande ci-dessous:

 Set-ExternalInOutlook –AllowList @{Remove="contoso.com","Anna@Fabrikam.com"} 

--> Étant donné que le balisage externe est un paramètre au niveau de l'organisation, il faudra un certain temps à Exchange Online pour que le tag soit activé. Cela peut prendre 24 à 48 heures.

Quand choisir la règle de transport plutôt que la balise externe native?

Le balisage externe natif est un paramètre global et sa personnalisation est limitée par rapport à la règle de transport. Si l'organisation a besoin d'exigences plus précises pour ajouter/exclure le balisage externe, vous devez opter pour la règle de transport.