Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

[Exchange Hybride] Erreur de planification de délégation des équipes dans Outlook

Scénario

Dans un déploiement Exchange hybride, les autorisations de délégation sont définies pour que l’utilisateur puisse créer des réunions Teams. Sur Outlook, lorsqu’il crée une réunion Teams pour d’autres utilisateurs Exchange onprem, une erreur Microsoft Teams s’affiche avec le message ci-dessous:

La solution est que l’utilisateur doit encore accorder d’autres droits d’accès aux délégués afin que les délégués peuvent envoyer des éléments notamment créer et répondre à des demandes de réunion.

– Accéder à la boîte aux lettres depuis laquelle les autorisations seront accordées aux délégués puis cliquer sur Paramètres du compte –> Accès délégué

– Cliquer sur Ajouter puis sélectionner l’utilisateur qui sera le délégué et cliquer sur OK.

– Choisir Auteur (peut lire et créer des éléments) ou Éditeur (peut lire, créer et modifier des éléments) et cliquez sur OK.

– L’utilisateur apparaît dans la liste des délégués, cliquer sur OK.

Vérifier par la suite que le délégué peut créer des réunions Teams dans Outlook. Si l’erreur persiste, fermer Microsoft Teams et Microsoft Outlook. Démarrer d’abord Microsoft Teams et une fois connecté, démarrer Microsoft Outlook ou encore redémarrer la machine.

Intune : Règle de conformité – Paramètre personnalisé Domain Joined

Dans Intune, nous pouvons utiliser les règles de conformité afin de détecter les appareils qui ne répondent pas aux exigences de l’entreprise.

Ces règles de conformité ont des paramètres par défaut, mais on peut créer nos paramètres personnalisés.

Dans cet article, nous allons configurer un paramètre personnalisé de conformité afin de détecter les appareils qui sont dans le domaine de l’entreprise (OnPrem et Entra ID).

Le script pour détecter le domaine/tenant de l’entreprise est le suivant :

### DOMAIN JOIN
$subKey = Get-Item "HKLM:/SYSTEM/CurrentControlSet/Control/CloudDomainJoin/TenantInfo" -ErrorAction Ignore
if ($subKey)
{
    $TenantID = $subKey.GetSubKeyNames()
    $TenantIDSubKey = $subkey.OpenSubKey($TenantID);
    $TenantName = $TenantIDSubKey.GetValue("DisplayName");
}

$hash = @{"TenantID" = $TenantID; "TenantName" = $TenantName}

return $hash | ConvertTo-Json -Compress

Ce script sera configuré dans : Intune –> Compliance –> Scripts

Une fois créé, ce script nous servira comme paramètre personnalisé dans notre règle de conformité (personnalisée) dans : Intune –> Compliance –> Policies

[Powershell] – Importer un certificat dans le store user d’un gMSA

J’ai récemment eu besoin d’importer un certificat dans le magasin personnel d’un gMSA pour m’en resservir dans un script plus tard.

Contrairement à un compte standard, il n’est en effet pas logique / « possible » d’ouvrir une session et d’importer le certificat directement depuis la session du gMSA, par conséquent il me fallait une autre solution.

Pour cela j’ai onc utilisé une tache planifié et un script Powershell.

Le code

Ce que je vous invite à faire, c’est de faire vos modifications et signer votre script afin de ne pas avoir à bypass ou modifier les policies.

$params = @{
    FilePath = 'C:\temp\CertForgMSA.pfx'
    CertStoreLocation = 'Cert:\CurrentUser\My'
    Password = ConvertTo-SecureString -AsPlainText "MyUltraS3curePassword" -Force
}
Import-PfxCertificate @params

 

Donc ici dans les paramètres j’ai :

  • FilePath : Représente le chemin de mon script 
  • CertStoreLocation : Représente le store du gMSA
  • Password : Le mot de passe du PFX (essayez d’en utiliser un plus secure 😀 )

Créer la tâche

J’ai déjà présenté dans l’article ICI comment faire, nous allons donc le faire un Powershell maintenant.

$TaskAction = New-ScheduledTaskAction -Execute C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe  -Argument "-File C:\Temp\ImportPfx.ps1"
 
$TaskTrigger = New-ScheduledTaskTrigger -At 00:00 -Once # vous pouvez utiliser d'autre valeurs selon vos besoin Par exemple Daily
 
$TaskPrincipal = New-ScheduledTaskPrincipal -UserID Lab\gMSA01$ -LogonType Password
 
Register-ScheduledTask MygMSATask –Action $TaskAction –Trigger $TaskTrigger –Principal $TaskPrincipal

 

Et voilà, il n’y a plus qu’a attendre que la tâche s’exécute; on peut également vérifier via une commande supplémentaire que le script est bien présent (Get-Item sur le store user avec un export dans un fichier texte par exemple).