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 l'antivirus de l'entreprise installé.
Le script pour détecter l'installation de l'Antivirus est le suivant :
N.B : Dans cet exemple, l'antivirus est Sophos :
### SOPHOS ANTIVIRUS
$SophosApp = (Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\Sophos Endpoint Agent" -ErrorAction Ignore | Select PSChildName).PSChildName
$hash = @{"SophosApp" = $SophosApp}
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
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
Dans le cas où un appareil Windows Autopilot n'arrive pas à s'activer en utilisant la clé OEM intégrée, ceci peut être à cause d'un serveur KMS que l'appareil essaye de contacter sur le réseau local de l'entreprise (à cause d'une mauvaise masterisation).
Afin de corriger cela et activer Windows en utilisant la clé OEM intégrée, on peut utiliser un script de remédiation Intune.
Script de détection / remédiation :
$key = (Get-WmiObject -query 'select * from SoftwareLicensingService').OA3xOriginalProductKey
$KMSservice = Get-WMIObject -query "select * from SoftwareLicensingService"
$null = $KMSservice.InstallProductKey($key)
$null = $KMSservice.RefreshLicenseStatus()
Dans le cas des appareils dans l'AD OnPrem, Co-Managed et gérés par Intune, il est pratique d'avoir la clé BitLocker enregistrée dans Entra ID afin de la visualiser dans le portail Intune.
La sauvegarde de la clé BitLocker vers Entra ID est possible en utilisant un script de remédiation Intune.
Script de détection :
try{
$BLV = Get-BitLockerVolume -MountPoint $env:SystemDrive
$KeyProtectorID=""
foreach($keyProtector in $BLV.KeyProtector){
if($keyProtector.KeyProtectorType -eq "RecoveryPassword"){
$KeyProtectorID=$keyProtector.KeyProtectorId
break;
}
}
$result = BackupToAAD-BitLockerKeyProtector -MountPoint "$($env:SystemDrive)" -KeyProtectorId $KeyProtectorID -whatif
return $true
}
catch{
return $false
}
Script de remédiation :
try{
$BLV = Get-BitLockerVolume -MountPoint $env:SystemDrive
$KeyProtectorID=""
foreach($keyProtector in $BLV.KeyProtector){
if($keyProtector.KeyProtectorType -eq "RecoveryPassword"){
$KeyProtectorID=$keyProtector.KeyProtectorId
break;
}
}
$result = BackupToAAD-BitLockerKeyProtector -MountPoint "$($env:SystemDrive)" -KeyProtectorId $KeyProtectorID -whatif
return $true
}
catch{
return $false
}
Le script de remédiation Intune ci-dessous permettait de fixer le bug d'upgrade de Windows Pro à Enterprise via licence 365.
Script de détection / remédiation :
# Define the registry key path and value
$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew"
$registryValueName = "Verify Multifactor Authentication in ClipRenew"
$registryValueData = 0 # DWORD value of 0
$sid = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-4") # Interactive group SID
# Check if the registry key already exists
if (-not (Test-Path -Path $registryPath)) {
# If the key doesn't exist, create it and set the DWORD value
New-Item -Path $registryPath -Force | Out-Null
Set-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -Type DWORD
Write-Output "Registry key created and DWORD value added."
} else {
Write-Output "Registry key already exists. No changes made."
}
# Add read permissions for SID (S-1-5-4, interactive users) to the registry key with inheritance
$acl = Get-Acl -Path $registryPath
$ruleSID = New-Object System.Security.AccessControl.RegistryAccessRule($sid, "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($ruleSID)
Set-Acl -Path $registryPath -AclObject $acl
Write-Output "Added 'Interactive' group and SID ($sid) with read permissions (with inheritance) to the registry key."
# Start the scheduled task
Get-ScheduledTask -TaskName 'LicenseAcquisition' | Start-ScheduledTask
Write-Output "Scheduled task 'LicenseAcquisition' started."
Afin de désactiver le compte Administrateur local par défaut dans Windows, ceci peut être simple en utilisant un script de remédiation Intune.
Script de détection :
$user = (Get-WmiObject -Class Win32_UserAccount -Filter 'LocalAccount = True ' | Where-Object SID -Like 'S-1-5-*-500').Name
$Status= (Get-WmiObject -Class Win32_UserAccount -Filter 'LocalAccount = True ' | Where-Object SID -Like 'S-1-5-*-500').Disabled
if ($Status -eq $false)
{
Write-Host "$user is Enabled"
Exit 1
}
Else {
Write-Host "$user is not Enabled"
Exit 0
}
Script de remédiation :
$user = (Get-WmiObject -Class Win32_UserAccount -Filter 'LocalAccount = True ' | Where-Object SID -Like 'S-1-5-*-500').Name
$Status= (Get-WmiObject -Class Win32_UserAccount -Filter 'LocalAccount = True ' | Where-Object SID -Like 'S-1-5-*-500').Disabled
if ($Status -eq $false)
{
try{
NET USER $user /active:No
Exit 0
}
Catch {
Write-Host "$user is already Disabled"
Write-error $_
Exit 1
}
}
Else {
Write-Host "$user is already Disabled"
Exit 1
}
Par mesure de sécurité, il est conseillé de désactiver le "Webmail" dans Adobe Acrobat Reader.
Ceci est possible en utilisant un script de remédiation dans Intune.
Script de détection :
$regkey64 = "HKLM:\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown\cWebmailProfiles"
$regkey32 = "HKLM:\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown\cWebmailProfiles"
$name = "bDisableWebmail"
try
{
$exists64 = Get-ItemProperty $regkey64 $name -ErrorAction SilentlyContinue
$exists32 = Get-ItemProperty $regkey32 $name -ErrorAction SilentlyContinue
#Write-Host "Test-RegistryValue: $exists"
if ((($exists64 -eq $null) -and ($exists32 -eq $null)) -or (($exists64.bDisableWebmail -ne 1) -and ($exists32.bDisableWebmail -ne 1)))
{
Write-Host "Webmail enabled"
exit 1
}
else
{
Write-Host "Webmail disabled"
exit 0
}
}
catch
{
return $false
}
Script de remédiation :
$regkey64 = "HKLM:\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown\cWebmailProfiles"
$regkey32 = "HKLM:\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown\cWebmailProfiles"
$name = "bDisableWebmail"
New-item -Path $regkey64 -ErrorAction SilentlyContinue
New-item -Path $regkey32 -ErrorAction SilentlyContinue
New-ItemProperty -Path $regkey64 -Name $name -Value "1" -PropertyType "DWORD" -Force -ErrorAction SilentlyContinue
New-ItemProperty -Path $regkey32 -Name $name -Value "1" -PropertyType "DWORD" -Force -ErrorAction SilentlyContinue
Le script ci-dessous archive des fichiers de log plus ancien que $daysthreshold vers une archive zip existante ($zipfilepath). Il crée le sous dossier et l'archive zip horodatée si elle n'existe pas.
ArchiveLogToZip.ps1
###############################################################
### ArchiveLogs.ps1 ###
### Add Log Files older than $days to existing zip archive. ###
### Params
### $logpath: Log Folder
### $archpath: Archive Folder
### $zipfilePath: zip file path
### $daysthreshold: Treat log older than $daysthreshold days
###############################################################
Param(
$logpath = "C:\MyLogFolder",
$archpath = "C:\MyLogFolder\Archive\",
$zipfilePath = "$archpath"+"*.zip",
[int]$daysthreshold = 0
)
# Test if $archpath exist
If ( -not (Test-Path $archpath)) {New-Item $archpath -type directory}
# Get items to archive
$ItemsToArc = Get-Childitem -Path $logpath -recurse | Where-Object {$_.extension -eq ".log" -and $_.LastWriteTime -lt (get-date).AddDays(-$daysthreshold)}
# Log and exit if No items to archive
If (! $ItemsToArc)
{
Write-Host -F Yellow "No items to archive - Check the existence of the logs"
exit 0
}
# If the zip file not exist, create it
if (!(Get-Item $zipfile -ErrorAction SilentlyContinue))
{
$date = $(Get-Date).ToString("MM-dd-yyyy_HH-mm-ss")
New-Item -Path "$archpath$date.zip"
$zipfile = $(Get-Item "$archpath$date.zip").FullName
}
Else
{
$zipfile = $(Get-Item $zipfilePath).FullName
}
# Create a com object that will represent the zip file
$Zip = New-Object -ComObject Shell.Application
write-progress -activity "Archiving Data" -status "Progress..."
try
{
$ItemsToArc | foreach {$Zip.namespace($zipfile).Movehere($_.fullname,8) ; start-sleep -Seconds 3}
}
catch
{
Write-Host "Error during File add to Zip"
}
Contexte
Lors d’un passage d’un Rollup Update ou d’un Service Pack (voir lors de l’utilisation d’un script PowerShell fourni par Microsoft), l’assistant d’installation d’Exchange 2010 échoue et l’erreur suivante est présente dans les logs :
Flow of control cannot leave a Finally block.
Solution
L’erreur provient d’une incompatibilité entre votre version de PowerShell et le script.
Pour résoudre l’erreur il faut regarder dans le fichier de log quel script et quelle ligne pose problème.
Ici c’est le script ManageScheduledTask.ps1 ligne 462 qui contient la commande return $success qui est en erreur.
Pour la résoudre il faut remplacer le return $success par Write-Output $success.
Une fois le script modifié, relancer l’assistant d’installation.
Contexte
Dans un environnement Office 365 il peut être nécessaire de savoir quelles fonctionnalités (Exchange, Skype, Yammer...) sont actives sur les utilisateurs.
Script
J'ai écrit le script suivant afin de récupérer automatiquement ces informations :
Get-UsersO365Features.ps1 (6,44 kb)
Pré-requis :
- Avoir un compte administrateur dans Office 365
- Avoir un dossier C:\temp\ sur sa machine
Limites :
- Actuellement le script ne prend en compte que les licences E1, E3 et K1
Résultat :
Une fois le script exécuté, vous avez dans le dossier C:\temp\ un dossier Export contenant :
- Trois fichiers contenant l'ensemble des utilisateurs et leur utilisation
- Trois dossiers contenant chacun le nombre de fonctionnalités actives et inactives
Licence du script :
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.