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. 

Description du problème :

Lorsqu’un utilisateur 1 n'a plus besoin d'accéder au calendrier d’un autre utilisateur 2, la délégation peut être supprimée via le client Outlook ou par un administrateur Exchange en utilisant le PowerShell.

Après la suppression des droits de délégation, tout accès au calendrier est révoqué et les invitations aux réunions ne sont plus envoyées au délégué pour qu'il les accepte ou les refuse. Il est possible que même après la suppression des délégations, l'utilisateur 1 continue à recevoir des demandes de réunions envoyées à l’utilisateur 2.

 Diagnostic et résolution :

• Vérifier si les droits délégués ont été correctement supprimés en exécutant la commande suivante: 

Get-MailboxFolderPermission -Identity UserEmailaddress:\Calendar  Si vous voyez encore l’ancien délégué, supprimez ses droits à l'aide de la commande: Remove-MailboxFolderPermission -Identity DelegatorUserEmailaddress:\Calendar -User UserEmailaddressdelegate

• Vérifier s’il y a des règles de boîte de réception masquées : Si le droit de voir les éléments privés a été affecté au délégué, une règle de boîte de réception masquée sera créée au niveau de la boîte aux lettres du délégué. Lorsque ce dernier est supprimé du calendrier, il doit automatiquement supprimer la règle masquée depuis sa Boite aux lettres.

Les règles de boîte de réception masquées ne sont pas visibles pour l'utilisateur dans Outlook. Seul un administrateur Exchange peut les chercher et les supprimer. Rechercher la règle de boîte de réception masquée via la commande :

Get-InboxRule -Mailbox  “DelegatorUserEmailaddress” -IncludeHidden avec le paramètre Mailbox identifiant le délégant et non le délégué. 

Ci-dessous un exemple du résultat de la commande précédente pour une boîte aux lettres avec une règle de boîte de réception de délégué masquée :

Pour en savoir plus sur ce que fait cette règle, développez la commande précédente avec l'ajout du paramètre Identity. Notez que le paramètre identité n'est pas le nom de la règle mais plutôt la valeur de RuleIdentity 

Vous pouvez supprimer cette règle avec la cmdlet "Remove-InboxRule" : Get-InboxRule -Mailbox EmailAddress -IncludeHidden -Identity  XXXXXXXXXXXXX | Remove-InboxRule

Confirmer la suppression de la règle en réémettant la commande initiale :

Get-InboxRule -Mailbox EmailAddress -IncludeHidden

La suppression de la règle du transfert au délégué devrait résoudre le problème.

Sinon, vérifiez si le transfert de boîte aux lettres est configuré via une redirection: Get-Mailbox -Identity “DelegatorUserEmailaddress”  | Format-List Name,ForwardingSmtpAddress,ForwardingAddress Si un transfert de boîte aux lettres est présent, les valeurs seront renvoyées dans les champs ForwardingSmtpAddress et ForwardingAddress. Si ces champs sont vides, le transfert de boîte aux lettres n'est pas en place.

Pour supprimer la configuration du transfert depuis une BAL, exécutez la commande suivante:Set-Mailbox -Identity “DelegatorUserEmailaddress”  -ForwardingSmtpAddress $null -ForwardingAddress $null -DeliverToMailboxAndForward $false

Il est aussi possible que le transfert soit en place avec une règle standard au niveau de la boîte de réception de l’utilisateur. Pour cela, vérifiez si les règles de la boîte de réception incluent une action de transfert ou de redirection.

Problématique:

Si vous avez plusieurs GAL dans l'environnement de messagerie séparées à l'aide de politiques de carnet d'adresses, un utilisateur de la GAL1 peut afficher les informations de contact de l'utilisateur GAL2. Pour éviter ça, vous pouvez activer l'agent de routage ABP.

Le routage des stratégies de carnet d’adresses contrôle la façon dont les destinataires sont résolus dans les organisations utilisant des stratégies de carnet d’adresses. Lorsque l'agent de routage ABP (Address Book Policy) est installé et configuré, les utilisateurs affectés à différentes listes d’adresses globales (GAL) apparaissent en tant que destinataires externes.

Pour Installer l'agent de routage des stratégies de carnet d'adresses :

1. Exécuter la commande suivante dans un environnement Exchange powershell :

Install-TransportAgent -Name "ABP Routing Agent" -TransportAgentFactory "Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent.AddressBookPolicyRoutingAgentFactory" -AssemblyPath $env:ExchangeInstallPath\TransportRoles\agents\AddressBookPolicyRoutingAgent\Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent.dll

Ignorer pour le moment le message d’avertissement indiquant que le service de transport doit être redémarré pour que vos modifications soient appliquées et passer à l'étape 2 de manière à ne redémarrer le service de transport qu'une seule fois.

2. Activer l’agent en exécutant la commande suivante :

Enable-TransportAgent "ABP Routing Agent"

3. Redémarrer le service de transport en exécutant la commande suivante :

Restart-Service MSExchangeTransport

4. Après le redémarrage du service, vérifier que l'agent de routage des stratégies de carnet d'adresses est installé et activé en exécutant la cmdlet suivante :

Get-TransportAgent

Si l’agent de routage de carnet d’adresses est répertorié, donc il a été correctement installé.

5. Activer par la suite le routage des stratégies de carnet d'adresses pour l'organisation en exécutant la commande suivante :

Set-TransportConfig -AddressBookPolicyRoutingEnabled $true

Désormais, les autres utilisateurs de la liste d’adresses globale GAL1 ne peuvent plus afficher les autres utilisateurs de la liste d’adresses globale GAL2

Scénario:

Créer un groupe d'appreils dynamique dans Azure AD qui regroupe les ordinateurs qui sont gérés par Intune ou Co-managed (Mode de gestion hybride: MECM+INTUNE).

Solution:

Dans Azure AD, créer un groupe d'appareils dynamique en utilisant une règle d'appartenance dynamique basée sur la propriété Mobile Device Management Type.

Dans la configuration de la règle, nous devons sélectionner la propriété deviceManagementAppId.

En tant que valeur, il faut renseigner l'un des identifiants ci-dessous :

• 54b943f8-d761-4f8d-951e-9cea1846db5a pour Co-managed
• 0000000a-0000-0000-c000-000000000000 pour Intune

Exemple:

Ceci est un exemple de configuration d'une règle dynamique pour un groupe d'appareils Co-managed:

Selon l'opérateur que vous préférez, vous devez entrer l'intégralité de l'ID ou pouvez utiliser une partie de l'ID.

Le script ci-dessous propose de rechercher dans une liste de dossiers specifiques (expression regulière FolderPattern) des fichiers de logs plus ou moins anciens, selon un seuil prédéfini (TimeDelta), ajoute un statut au tableau selon le cas rencontré, et exporte le resultat en fichier csv.

##############################################
### CHECK OLD LOG FILES ###
##############################################


<# 

    .SYNOPSIS 
        VERIFICATION DE LA PRESENCE ET DE L'ANCIENNETE DU LOG LE PLUS RECENT DANS UNE LISTE DE DOSSIER; 
        UN TABLEAU DES DOSSIERS DONT LE LOG LE PLUS RECENT EST PLUS ANCIEN QUE J-$TimeDelta EST AFFICHE ET EXPORTE EN FICHIER CSV.  

    .PARAMETER  
        RootFolder : Chemin du dossier racine
        TimeDelta : Seuil d'ancienneté du fichier de log le plus recent
        FolderPattern: Expression reguliere pour selectionner des noms de sous dossier
        

 
    .EXAMPLE 
     .\Check_Old_Log_Folders.ps1 -RootFolder "C:\MyRootFolder" -TimeDelta 15
#>




[CmdletBinding()]
param(
[Parameter(Mandatory,HelpMessage="Chemin du dossier racine")]
$RootFolder,

[Parameter(Mandatory,HelpMessage="Seuil d'ancienneté du fichier de log le plus recent")]
$TimeDelta,

[Parameter(HelpMessage="Expression reguliere pour selectionner des noms de sous dossier")]
[regex]$FolderPattern = "^(SRV|DEV).*"

)



# Date du jour - TimeDelta
$DateTimeMinus = (get-date).AddDays(-$TimeDelta)

# Verification que RootFolder existe 
if (!(Test-Path -Path $RootFolder))
    {
    write-host -B White -F Red "UNABLE TO FIND $RootFolder - CHECK PATH - END OF SCRIPT"
    EXIT 1
    }


# Creation d'un PSobject pour stocker les futurs valeurs LogFolder,LastLog et Status
$FileTab = @()

# Recuperation des noms de dossier
$Folders = Get-ChildItem -Path $RootFolder -Directory | Where-Object {$_.Name -match $FolderPattern}


# Pour chacun des dossier on cherche le dernier fichier modifié
$Folders | foreach {


$LogFolder = $_.Name
$LastLog = Get-ChildItem -Path $_.FullName | select -Last 1 -Property LastWriteTime -ExpandProperty LastWriteTime

# Si le dossier est vide (pas de Lastlog) le status est KO
 if (!$LastLog) {$status = "KO - DOSSIER VIDE"}

# Si LastLog est plus ancien ou plus recent que $DateTimeMinus  
 switch($LastLog)
    {
        
        {$LastLog -lt $DateTimeMinus} {$status = "KO - OLDER THAN $DateTimeMinus"}
        {$LastLog -gt $DateTimeMinus} {$status = "OK - NEWER THAN $DateTimeMinus"}
        default {$status = "UNKNOWN"}
    }


# remplissage du tableau
$FileTab += New-Object -TypeName psobject -Property @{LogFolder=$LogFolder;LastLog=$LastLog;Status=$status}

}


# Affiche le tableau $FileTab des dossiers dont le fichier le plus recent est plus ancien que $TimeDelta ou pour lequel il n'y a pas de log
Write-Host -F red -B White "LOG FOLDERS DONT LE FICHIER DE LOG LE PLUS RECENT EST PLUS ANCIEN QUE J $TimeDelta OU POUR LESQUELS IL N'EXISTE PAS DE LOG (DOSSIER VIDE)"
$KOFiles = $FileTab | Where-Object {$_.status -like 'KO*'} | select LogFolder,LastLog,Status | Sort LastLog
$KOFiles | ft -AutoSize


# Export CSV du tableau en supprimant les caractere '"'
$KOFilesCSV = $KOFiles | ConvertTo-Csv -Delimiter "," -NoTypeInformation | ForEach {$_.replace('"','')}


# Export du fichier CSV
$KOFilesCSV | Out-File "$($pwd.ProviderPath)\OldLogFolders.csv" -Force
write-host -F Blue -B White "Old Log Folders CSV File Exported as $($pwd.ProviderPath)\OldLogFolders.csv"


# Ouverture du fichier CSV
notepad.exe "$($pwd.ProviderPath)\OldLogFolders.csv"

Contexte :

Dans le cas ou vous implémentez l'Active Directory Split Model Permission, vous réduisez les permissions de l'Exchange sur L'AD et par conséquent une partie des commandes disponible depuis l'Exchange.

Problème :

La modification doit être faite sur les fiches des objets AD et il faut connaitre l'attribut à modifier.

Par exemple pour autoriser un ou des utilisateur(s) à écrire à une liste de distribution, il faut pour chaque utilisateur ajouter son "DistinguishedName" dans l'attribut "authOrig" de la liste en question.

Solution :

Si vous ne souhaitez pas éditez les fiches AD, aller dans l'onglet éditeur d'attributs et éditer / modifier l'attribut (déjà 4 clics avec la validation) vous pouvez utiliser Powershell avec la ligne de commande suivante :

Set-ADGroup -Identity "SamAccountName_Du_Groupe" -Add @{authOrig=@("DistinguishedName_Du_User")}

Mais si vous devez le faire pour plusieurs utilisateurs et ne pas traiter cela unitairement, il vous est possible d'utiliser la fonction suivante en passant plusieurs utilisateurs pour l'attribut "SamAccountName" séparés par une virgule :

Function Allow-ToSendTo {
    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 @{authOrig=@($CurrentUser.DistinguishedName)} -ErrorAction Stop
                }
                Catch {
                    Write-Warning $($_)
                    }
            }
            Catch {
                Write-Warning $($_)
            }
        }
    }
    Catch {
        Write-Host "Group Not found sorry" -ForegroundColor Yellow
    }
}

Une présentation des Administrative Units (AU) a été réalisée dans l'article suivant : Azure - présentation des Administrative Units

La délégation des Administrative Units en interface graphique a été expliquée dans l'article suivant :  Azure - déléguer les Administrative Units

Créer et déléguer des Administrative Units en PowerShell

#Import les modules AzureAD et AzureADPreview qui contient les commandes utilisées pour la création des Administrative Units (AU)
#Si certaines commandes ne sont pas reconnues, assurez vous d'avoir le module à jour avec la commande Update-Module
Import-Module AzureAD
Import-Module AzureADPreview

#Initie une connexion avec AzureAD dans la console PowerShell, un compte avec les droits Global Administrator ou Privileged Role Administrator est nécessaire
Connect-AzureAD

#Création d'une nouvelle AU, la commande est sauvegardé dans une variable car l'objectID doit être utilisé pour la délégation
#Par défaut l'affectation des objets à l'AU sera Assigned, pour faire de l'affectation dynamique utiliser les paramètres MembershipType, MembershipRuleProcessingState et MembershipRule 
New-AzureADMSAdministrativeUnit -Description "Test Administrative Unit created with PowerShell" -DisplayName "AdministrativeUnit-test2"

#Les propriétés de l'AU sont récupérées car l'object ID est nécessaire pour faire l'affectation des droits au groupe de délégation dans PIM
$NewAU = Get-AzureADAdministrativeUnit -Filter "displayname eq 'AdministrativeUnit-test2'"

#Création d'un groupe de délégation qui aura la délégation sur l'AU créée
#C'est un groupe de sécurité, la partie mail est donc désactivé (MailEnabled $False) et la partie sécurité est activé (SecurityEnabled $True)
#Le paramètre MailNickname est obligatoire, il est donc recommandé de rentrer la même valeur que le displayName
#Pour pouvoir affecter des rôles via PIM, il est nécessaire d'activer le paramètre IsAssignableToRole
#Le paramètre Visibility permet de modifier qui est autorisé à voir les membres du groupe, il est recommandé de choisir soit Private soit HiddenMembership
New-AzureADMSGroup -DisplayName "Group-to-manage-AdministrativeUnit-test2" -Description "Group that have the delegation on the AU AdministrativeUnit-test2" `
-MailEnabled $False -MailNickname "Group-to-manage-AdministrativeUnit-test2" -SecurityEnabled $True -IsAssignableToRole $True -Visibility "Private"

#L'affectation des droits au groupe de délégation dans PIM via la commande New-AzureADMSRoleAssignment nécessite l'ID du groupe de délégation
$NewAzureGroup = Get-AzureADGroup -Filter "displayname eq 'Group-to-manage-AdministrativeUnit-test2'"

#L'affectation des droits au groupe de délégation dans PIM via la commande New-AzureADMSRoleAssignment nécessite l'ID du rôle
#Cet ID peut être récupérer depuis portal.azure.com > Azure Active Directory > Administrative Units > {Cliquer sur une AU existante} >
#Roles and admininistrators > {Choisir le rôle a affecté} > Description > Template ID
#Le template ID choisi est celui d'User administrator
$RoleDefinitionID = Get-AzureADMSRoleDefinition -ID "fe930be7-5e62-47db-91af-98c3a49a38b1"

#L'affectation des droits au groupe de délégation dans PIM via la commande New-AzureADMSRoleAssignment nécessite l'ID de l'AU
$DirectoryScopeId = '/administrativeUnits/' + $NewAU.ObjectId

#Création de la délégation PIM du groupe Group-to-manage-AdministrativeUnit-test2 sur l'AU AdministrativeUnit-test2
New-AzureADMSRoleAssignment -DirectoryScopeId $DirectoryScopeId -RoleDefinitionId $RoleDefinitionID.Id -PrincipalId $NewAzureGroup.ObjectId

Vérification de la création et de la délégation

L'Administrative Unit a bien été créé

Le groupe de délégation ainsi que son affectation dans PIM est effective

Remarque : lors de l'installation du module AzureADPreview, celui-ci entre en conflit avec le module AzureAD s'il est déjà installé, lors de l'utilisation de la commande Install-Module, utiliser les paramètres AllowClobber et Force

Pour aller plus loin

Documentation officielle de la commande New-AzureADMSAdministrativeUnit
Documentation officielle de la commande Get-AzureADAdministrativeUnit
Documentation officielle de la commande New-AzureADMSGroup
Documentation officielle de la commande Get-AzureADGroup
Documentation officielle de la commande Get-AzureADMSRoleDefinition
Documentation officielle de la commande New-AzureADMSRoleAssignment

Une présentation des Administrative Units (AU) a été réalisée dans l'article suivant : Azure - présentation des Administrative Units

Créer et déléguer une Administrative Unit

Lorsqu'une Administrative Unit est en phase de création, il est proposé de réaliser la délégation via Privileged Identity Management (PIM).

Création d'une Administrative Unit

Choix du nom de la nouvelle AU

En bas de la blade choisir Next: Assign roles >

Affecter les rôles qui doivent être délégués à des utilisateurs.

Remarque : il n'est pas possible d'affecter des groupes depuis cette blade, néanmoins il est possible de le faire après que l'AU soit créé en l'éditant.

Dans l'exemple suivant, le rôle User Administrator sera affecté

Une fois l'affectation faite, finir la création en cliquant sur Next: Review + create >

Puis Create

L'Administrative Unit créé est alors affiché

Déléguer une Administrative Unit à un groupe

Cliquer sur le nom de l'AU précédemment créée, puis sous Manage choisir la blade Roles and administrators et clique sur le rôle a délégué

La blade affichée n'est plus la même que lors de la création de l'AU, c'est la blade de délégation PIM qui s'affiche. Cliquer sur Active assignments puis Add assignments

Cliquer sur No member selected et choisir le groupe à déléguer

Cliquer sur Next

Choisir le mode d'affectation, il est recommandé de choisir un Assignment type Active avec une durée d'affectation Permanently assigned étant donné que les AU sont déjà restreintes en termes de périmètre et des opérations disponibles.

Clique sur Assign

Les affectations sont visibles depuis le sous-menu PIM précédémment évoqué

Les délégations des Administrative Units les plus utiles en septembre 2022

Remarque : il n'est pas possible de créer des utilisateurs directement depuis une AU

Remarque 2 : les autres rôles donnent soient trop de permissions et ne sont pas conseillés, car proche des droits sur tout le tenant soit n'ont aucune répercussion de délégation.

Pour aller plus loin

Sur le même blog : PowerShell - créer et déléguer des Administrative Units

Les Administratives Unites (AU) sont similaires aux Organisational Units dans l'Active Directory OnPremises. Ce sont des containers logiques qui permettent de grouper des utilisateurs, des ordinateurs ou des groupes. L'affectation de ces objets peut être faie de 3 manières différentes : assigned, dynamic user et dynamic device. Les Administrative Units sont encore en cours de développement, mais quelques fonctionalités sont d'ores et déjà disponibles.

Les prérequis des Administrative Units

Une licence Azure AD Premium P1 est requise pour chaque utilisateur qui administre une AU.
Une licence Azure AD Free est nécessaire pour chaque membre d'une AU.

Dans le cas où une règle d'inclusion dynamique serait utilisée, chaque membre de l'ADU doit avoir une licence Azure AD Premium P1.

Pour pouvoir crééer, modifier ou supprimer des AU, il est nécessaire d'avoir soit le rôle Azure Global Administrator soit Privileged Role Administrator.

Accéder aux Administrative Units

Les Administrative Units peuvent être gérer via portal.azure.com > Azure Active Directory > Administrative Units

Depuis cette blade, il est possible de consulter la liste des Administrative Units déjà créés et de les ouvrir pour voir ce qu'elles contiennent. Il est également possible d'en créer de nouvelles avec le bouton Add.

Une fois dans une Administrative Units la blade Users est sélectionnée par défaut, l'ensemble des utilisateurs contenus dans l'AU sont listés au millieu de l'écran. Dans le menu Manage plusieurs blades sont disponibles

La blade Properties permet de choisir le nom de l'AU, sa description et la façon dont les objets sont provisionnés dans l'AU

Les blades Groups et Devices listent respectivement les groupes et les ordinateurs de l'AU.

La blade Roles and administrators permet d'affecter via PIM (Privileged Identity Management) des délégations sur l'AU.

Certains rôles, bien qu'ils puissent être affectés n'ont pas d'incidence sur les délégations des AU.

La blade Dynamic membership rules apparaît si l'affectation des objets à l'AU est dynamique, elle permet de choisir les règles d'inclusions des objets dans l'AU.

Pour aller plus loin

Sur le même blog : Azure - déléguer les Administrative Units

Sur le même blog : PowerShell - créer et déléguer des Administrative Units