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 :

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.

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.

Symptômes:

Lorsque vous essayez de supprimer l'autorisation « Accès total » ou « Envoyer en tant que »  sur une boite aux lettres, vous pouvez être confronté aux messages d’avertissements indiquant que l’entrée de contrôle d’accès ne peut pas être supprimée.

Ce problème apparaîtra quand vous essayez de supprimer l'autorisation à l'aide du PowerShell Exchange ou depuis l'interface graphique.

•  A la suppression de l’autorisation « Envoyer en tant que» via la console d’administration ECP, vous aurez  le message d’avertissement ci-dessous :
• Quand vous supprimez l’autorisation « Accès total» , pas de message d’avertissement , mais la délégation n’est pas supprimée.
• A la suppression de l’autorisation « Full Access/ send as » depuis une BAL en powershell,  vous aurez les messages d’avertissement suivants :

Solution:

Les étapes suivantes s'appliquent pour les boites aux lettres liées. La solution de contournement consiste à déconnecter la BAL de l'utilisateur, modifier les autorisations puis la reconnecter :

Exemple : Supprimer l’autorisation de User01 sur la BAL de User02:

• Exécutez la commande suivante: Set-User -Identity useridentity -LinkedMasterAccount $null Cette commande permet de dissocier la boîte aux lettres liée et la convertir en boîte aux lettres utilisateur.

  Le paramètre Identity spécifie l'utilisateur que vous souhaitez modifier. Vous pouvez utiliser n'importe quelle valeur qui identifie l'utilisateur de manière unique. Par exemple:

  • Name
  • Distinguished name (DN)
  • Canonical DN
  • GUID
  • UserPrincipalName

• Supprimez par la suite les autorisations en exécutant les commandes suivantes :

  Pour supprimer la délégation Full Access  Remove-MailboxPermission -Identity MailboxAccount -User UserAccount -AccessRights FullAccess -InheritanceType All

  Exemple:  Remove-MailboxPermission -Identity "user02" -User "User01" -AccessRights FullAccess -InheritanceType All

  Pour supprimer la délégation Send As  Remove-ADPermission -Identity "MailboxAccount" -User "UserAccount" -ExtendedRights "Send As"

  Exemple: Remove-ADPermission -Identity " User02" -User " User01" -ExtendedRights "Send As"

• Une fois les délégations supprimées, reconnectez de nouveau la boite aux lettres de l’utilisateur via la commande :

  Set-User -Identity “UserAccount” – LinkedDomainController “domaincontroller” -LinkedMasterAccount “DomainName\user”

  Exemple:  Set-User -Identity User01@contoso.com – LinkedDomainController dc01.contoso.com -LinkedMasterAccount “contoso\User01”

• Vérifier par la suite que les autorisations ont été bien supprimées.

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.