PI Services

Besoin d'avoir un état des lieux de vos licences O365 (voir de l'automatiser) ?

Voici quelques lignes Powershell qui vous remontrons les informations.

Prérequis:

Vous aurez besoin de:

• Powershell 5.1
• Le module Azure AD

Code :

Connect-AzureAD
$Array = @()
$AllSKU = Get-AzureADSubscribedSku

$AllSKU | sort SkuPartNumber | foreach {
    $SkuPartNumber = $_.SkuPartNumber
    $Bought = $_.PrepaidUnits.enabled
    $Suspended = $_.PrepaidUnits.Suspended
    $Warning = $_.PrepaidUnits.Warning
    $Assigned = $_.ConsumedUnits
    $Rest = $Bought - $Assigned

    $Array += New-Object psobject -Property @{
        License = $SkuPartNumber
        Bought = $Bought
        Assigned = $Assigned
        Will_Expired = $Warning
        Suspended = $Suspended
        Rest = $Rest
        }
    $SkuPartNumber = $null
    $Bought = $null
    $Assigned = $null
    $Warning = $null
    $Suspended = $null
    $Rest = $null
        
    }

$Array | FT License,Bought,Assigned,Will_Expired,Suspended,Rest
$Array | Export-Csv C:\temp\Licenses.csv -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Bien entendu, pour l'automatiser il faudra modifier l'authentification et passer par de la moderne authentification (via un SPN).

Une erreur de sécurité courante consiste à configurer les services pour utiliser un descripteur de sécurité trop permissif, et ainsi accorder par inattention l'accès et la gestion des services à plus d'appelants distants que prévu.

Depuis les versions Windows 10 version 1709 et Windows Server 2016 version 1709, Microsoft avait appliqué une nouvelle politique de sécurité. En vertu de cette nouvelle politique, seuls les administrateurs locaux peuvent gérer les services à distance. En effet, un nouveau paramètre de sécurité du système a été introduit qui exige que les appelants distants soient également des administrateurs locaux sur l'ordinateur pour pouvoir demander la liste des autorisation de service suivante :

• SERVICE_CHANGE_CONFIG
• SERVICE_START
• SERVICE_STOP
• SERVICE_PAUSE_CONTINUE
• SUPPRIMER
• WRITE_DAC
• WRITE_OWNER

Le nouveau paramètre de sécurité requiert également que les appelants distants soient des administrateurs locaux sur l'ordinateur pour demander l'autorisation de gestionnaire de contrôle de service suivante :

• SC_MANAGER_CREATE_SERVICE

Ce paramètre a été introduit à partir de Windows 10 version 1709 et de Windows Server 2016 version 1709. Par défaut, le paramètre est activé.

Cette nouvelle vérification peut causer des problèmes à certains clients dont les services reposent sur la possibilité pour les non-administrateurs de les démarrer ou de les arrêter à distance. Si nécessaire, vous pouvez exclure certains services de cette stratégie en ajoutant le nom du service à la valeur de registre RemoteAccessCheckExemptionList REG_MULTI_SZ à l'emplacement de registre suivant :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\SCM

Pour le faire, veuillez choisir une des deux méthodes suivantes :

Méthode 1 : Par interface graphique 

1. Dans le menu démarrer , accédez à la console regedit.exe .
2. Recherchez et sélectionnez la sous-clé suivante dans le Registre :
   
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\SCM
   
   Remarque  Si la sous-clé n'existe pas, vous devez la créer : Dans le menu Edition , sélectionnez  Nouveau , puis sélectionnez  Clé . Tapez le nom de la nouvelle sous-clé, puis appuyez sur Entrée.
3. Dans le menu Edition , pointez sur Nouveau , puis sélectionnez  Valeur REG_MULTI_SZ .
4. Tapez RemoteAccessCheckExemptionList  pour le nom de la valeur REG_MULTI_SZ, puis appuyez sur ENTRÉE.
5. Double-cliquez sur la valeur RemoteAccessCheckExemptionList , saisissez le nom du service à exempter de la nouvelle stratégie, puis cliquez sur OK .
6. Quittez l'Éditeur du Registre, puis redémarrez l'ordinateur.

Méthode 2 : Par commandes PowerShell

#récuperer le contenu de la clé de registre
$services = (Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecurePipeServers\SCM).RemoteAccessCheckExemptionList

#définir la liste des services à exclure de la politique de sécurité
$newservices= 'spooler','LPDSVC' 

#ajouter la nouvelle liste de services
foreach ($newsvc in $newservices)
{
$services += $newsvc +" "
}

#reconfigurer la clé de registre
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecurePipeServers\SCM -Name RemoteAccessCheckExemptionList -Value $services -Type Multistring 

Pour afficher le bouton SSPR (Self-Service Password reset) sur l'écran d'ouverture de session Windows 10, il faut ajouter la clé de registre ci-dessous manuellement ou via GPO (sous réserve d'avoir SSPR déjà activé pour l'utilisateur et l'ordinateurs est joint à Azure AD en mode Hybride) :

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount] 

"AllowPasswordReset"=dword:00000001 

Dans certains cas, même après l'ajout de cette clé de registre, le bouton SSPR ne s'affiche pas sur l'écran d'ouverture de session.

En regardant sur Azure AD, l'état de la machine qui n'a pas fonctionné, nous avons constaté qu'elle est bien Hybrid Azure AD Joined mais le statut d'enregistrement est en Pending

Afin de résoudre ce problème, il faut forcer l'enregistrement de la machine à Azure AD en ajoutant les deux valeurs de la clé de registre ci-dessous :

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD] 

"TenantId"="<YourTenantId>" 

"TenantName"="<YourCompany.com>" 

Une fois ajoutés, redémarrez l'ordinateur et il sera enregistré dans Azure AD.

Sur l'écran d'ouverture de session, le bouton SSPR doit maintenant s'afficher.

Une mise a jour du script proposé récemment, utilisant la nouvelle version de l'API de Vcenter.

### QUERY VCENTER REST API (v7) TO GET VM LIST ###


$user = ‘myaccount’
$pswd = Read-Host -Prompt "Enter Password"
$vCenterName = ‘MyVcenter’
$encoded = [System.Text.Encoding]::UTF8.GetBytes(($user, $pswd -Join ‘:’))
$encodedPassword = [System.Convert]::ToBase64String($Encoded)
$authHeader = @{
Authorization = "Basic $($EncodedPassword)"
}
$sRest = @{
Method = ‘Post’
Uri = "https://$($vCenterName)/api/session"
Headers = $authHeader
}
$result = Invoke-RestMethod @sRest


# Get TokenID
$authHeader = @{
‘vmware-api-session-id’ = $result.value
}


# Get All Hosts
$gethosts = "https://$($vCenterName)/api/vcenter/host"
$resultgethost = Invoke-RestMethod -Uri $gethosts -Headers $authHeader
$hostidlist = $resultgethost.value.host


# For each host, get all VMs

foreach ($hostid in $hostidlist)
{
$get_vm = "https://$($vCenterName)/rest/vcenter/vm?filter.hosts=$hostid"
$resultvm = Invoke-RestMethod -Uri $get_vm -Headers $authHeader
[array]$FinalTableau += $resultvm
}

# Display Result
$FinalTableau.value | select name,power_state


# Output to CSV
$CsvTab = $FinalTableau.value | select name,power_state | ConvertTo-Csv -Delimiter ';' -NoTypeInformation
$CsvTab | Out-File .\VMList.csv

 

Problème

Lorsqu'un utilisateur On premises tente de partager son calendrier avec un utilisateur Office 365, il reçoit le message d’erreur suivant :

Cause

Ce problème se produit si la stratégie de partage n’autorise pas l’utilisateur à partager le niveau de détails que l’utilisateur a défini dans l’invitation de partage.

Solution

Pour résoudre ce problème, suivez les étapes suivantes :

1. Ouvrez le Centre d’administration Exchange, cliquez sur Organization --> Sharing
2. Double-cliquez sur "Default Sharing Policy (DEFAULT)"
3. Cette règle indique que vous ne pouvez partager que l'autorisation « Disponibilité uniquement » avec les autres organisations.

   Vous pouvez soit modifier la règle de partage  « Toutes les informations de calendrier, notamment l'heure, l'objet, l'emplacement et le titre » pour tous les domaines

4. Ou vous créez une nouvelle règle de partage pour votre domaine smtp qui est partagé dans Office 365 et attribuez "Toutes les informations de calendrier, notamment l'heure, l'objet, l'emplacement et le titre". 
5. Cliquez ensuite sur "Enregistrer"

Dans Exchange 2016, vous remarquerez des messages d'erreurs  "MSExchange Autodiscover" avec l'Event ID 1 dans le journal des événements d'application du serveur :

Ce problème a été résolu dans Exchange 2016 CU15 et Exchange 2019 CU4, mais apparaît parfois dans des versions plus récentes.

Il s'agit d'un problème connu chez Microsoft et la solution de contournement est simple:

• Définissez la propriété ExternalURL du répertoire virtuel Autodiscover, comme ceci:

Get-AutodiscoverVirtualDirectory -Server | Set-AutodiscoverVirtualDirectory -ExternalUrl https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml

Si vous souhaitez utiliser TLS ou utilisez l'authentification TLS dans un environnement Office 365 hybride ou encore vous avez modifié ou renouvelé manuellement le certificat SSL, vous pouvez toujours obtenir des erreurs indiquant que vous ne pouvez pas lancer la session TLS (STARTTLS), même si le certificat SSL a été correctement renouvelé.

Il ne suffit pas de définir le certificat SSL à utiliser avec SMTP pour que TLS fonctionne correctement. Vous devez également (re)configurer le nom du certificat TLS sur vos connecteurs de réception.

Pour formater correctement le contenu du TlsCertificateName, vous pouvez l'extraire du certificat via des commandes ci-dessous.

• Dans un environnement Exchange Management Shell, récupérez les certificats actuels :

Get-ExchangeCertificate

• Vous obtiendrez une liste de tous les certificats, mais vous n'aurez besoin que de celui à utiliser pour TLS, que vous pouvez extraire en spécifiant son empreinte :

$cert = Get-ExchangeCertificate -Thumbprint DE67EC3C8D679DC35D171341FEC5148D012B1BAE2

• À partir de la variable précédemment créée, vous pouvez maintenant compiler la valeur pour le nom du certificat TLS :

$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"

• Avec la nouvelle variable, vous pouvez maintenant changer chaque connecteur de réception en activant le TLS et modifiant le nom du certificat TLS :
  Set-ReceiveConnector "Inbound from Office 365" -RequireTLS $True -TlsCertificateName $tlscertificatename

Lors de la préparation d'Active Directory pour Exchange 2016 ou pour l'installation d'CU à l'aide du commutateur /PrepareSchema pour un environnement existant d'Exchange hybride, l'erreur suivante est (parfois) générée :

Un problème similaire se produira si vous spécifiez uniquement /PrepareAD

--> Pour résoudre le problème il faut générer le fichier de configuration XML depuis le tenant office 365 puis l'utiliser avec la commande /PrepareAD.

• Pour générer le fichier de configuration XML, connectez-vous à Exchange Online à l'aide de PowerShell. Une fois connecté et authentifié, exécutez la commande suivante:

Get-OrganizationConfig | Export-Clixml -Path C:\Temp\MyTenantOrganizationConfig.XML

• Le commutateur /TenantOrganizationConfig ne peut être combiné qu'avec le commutateur /PrepareAD, il ne peut pas être utilisé avec  /PrepareSchema. Si vous le faites, cela générera un message d'erreur "Le paramètre 'tenantorganizationconfig' n'est pas valide pour l'opération en cours 'PrepareSchema'". Exécutez alors la commande ci-dessous dans un environnement CMD exécuté en tant qu'administrateur:

Setup.exe /PrepareAD /TenantOrganizationConfig C:\Temp\TenantOrganizationConfig.XML /IAcceptExchangeServerLicenseTerms

A noter:

Dans ce scénario, l'exécution du commutateur /PrepareAD déclenchera automatiquement le commutateur /PrepareSchema. Par conséquent, vous devez avoir en plus, les droits d’administrateur de schéma pour effectuer les modifications du schéma.