Manipulation du pagefile avec Powershell et scripting diskpart

Récemment, j'ai modifié mon template de machine virtuelle Windows Server porté par VMware pour y intégrer un deuxième disque virtuel afin d'y placer le fichier d'échange de Windows. Seulement, après génération de mon image Windows avec sysprep, mon deuxième disque n'est plus monté sur le système, et par conséquent ma configuration de fichier d'échange est invalide. J'ai donc dû traiter ce problème en deux temps : la première étape a été de faire en sorte de faire un batch pour diskpart afin de monter mon deuxième disque et l'initialiser correctement, et la deuxième étape a été de configurer le pagefile via Powshell afin de pouvoir intégrer le tout dans mon script de post-installation.

Tout d'abord, j'ai appris qu'il était possible de faire avaler à diskpart un fichier texte contenant les instructions qu'il doit exécuter à la suite. Par exemple, si je veux initialiser mon deuxième disque et affecter la lettre E à ma partition, je vais créer un fichier texte nommé "diskinit.txt" contenant ceci :

select disk 1
online disk
select partition 1
assign letter=E

Je conseille tout de même de tester une par une les commandes à la main pour s'assurer que cela fonctionne avant de les placer à la suite dans le fichier. Une fois que le fichier existe, il est possible d'appeler diskpart pour lui demander de traiter celui-ci, grâce au paramètre /s :

diskpart.exe /s diskinit.txt

Puisque cela fonctionne, j'ai dû m'atteler à la gestion du fichier d'échange sous Powershell. Il n'y a pas de commandlet natif sous Windows Server 2016 pour gérer le fichier d'échange comme un paramètre système standard. Il faut passer par WMI. Cette commande permet d'afficher les fichiers d'échange configurés sur la machine, uniquement si le fichier d'échange n'est pas gérée de manière automatique pour tous les disques du système :

Get-CimInstance -ClassName Win32_PagefileSetting

Maintenant que j'ai bien mon disque E:, je peux rajouter mon fichier d'échange sur cette partition et retirer celui présent sur le disque système.

New-CimInstance -ClassName Win32_PagefileSetting -Property @{Name "E:\pagefile.sys"}
Get-CimInstance -ClassName Win32_PagefileSetting | Where-Object { $_.Name -like "C:\pagefile.sys" } | Remove-CimInstance

A noter que cette instruction créée un fichier d'échange dont la taille est gérée par le système. Il est possible de spécifier une taille minimale et/ou maximale, en procédant par exemple comme ceci pour une taille mini de 1024 Mo et une taille maxi de 2048 Mo :

Get-CimInstance -ClassName Win32_PagefileSetting | Where-Object { $_.Name -like "E:\pagefile.sys" } | Set-CimInstance -Property @{InitialSize = 1024; MaximumSize = 2048}

Alternativement, ce qui est passé dans le dernier pipe peut être passé en pipe de l'instruction New-CimInstance exécutée en premier, afin d'avoir le bon réglage dès la création.

Vous pouvez trouver avoir bien plus de détails sur cette classe WMI et un script complet de gestion du pagefile via Powershell en suivant ce lien qui m'a aidé à comprendre et à scripter cette opération. 🙂

MS Exchange Toolbox

J'ai développé rapidement un script Powershell à interface graphique permettant de regrouper sous un seul écran les divers scripts qui me servent à l'administration quotidienne d'Exchange : création de boîte aux lettres, affectation de droits OWA, etc.

Bien que je n'aie pas développé cet outil dans le but précis de le partager ou de m'améliorer en Powershell avec, je me dis que c'est un peu idiot de garder le code d'un petit outil comme celui-ci pour moi et qu'il pourra éventuellement vous servir comme base pour quelque chose de plus gros ou simplement pour récupérer quelques snippets.

Naturellement, plus d'informations sont affichées notamment les adresses SMTP ainsi que l'alias, et les accès en ouverture comme envoi sur d'autres boîtes aux lettres si l'on le souhaite.

Chaque instruction voit son retour Powershell retourné dans la console en bas de fenêtre. Le script s'exécute directement depuis l'Exchange Management Shell mais il peut être appelé depuis un Powershell standard si l'on ajoute les bonnes références en début de script.

Exchange et Powershell : liste des permissions d'un user sur les mailbox

Ce script utilisable dans l'Exchange Management Shell prend en paramètre un nom de compte AD rattaché à une mailbox afin de parcourir toutes les ACL des boîtes aux lettres rattachées l'organisation. Il affiche les adresses SMTP reliées à la boîte aux lettres, puis les boîtes aux lettres auxquels le compte à accès ainsi que celles à partir desquelles il peut faire un envoi "en tant que" (Send As).

Une version commentée de ce script est disponible sur le lien ci-dessous.

param([Parameter(Mandatory=$true)][string]$Mailbox)
Write-Host "Processing queries, this might take a while!" -ForegroundColor "Yellow"
$localMbx = Get-Mailbox $Mailbox
$allMbx = Get-Mailbox -ResultSize Unlimited | select Alias
$sam = $localMbx.samAccountName
$validAcl = @()
$validSendAs = @()
foreach($Mbx in $allMbx) {
	$aclMbx = Get-MailboxPermission $Mbx.Alias | where-Object { $_.User -like "*$sam" -and $_.IsInherited -eq $false -and $_.AccessRights -contains "FullAccess" -and $_.Deny -eq $false } 
	if($aclMbx -ne $null) {
		$aclMbx | % { $validAcl+=$_.Identity }
	}
	$sendAsMbx = Get-RecipientPermission $Mbx.Alias | Where-Object { $_.Trustee -like $localMbx.OrganizationalUnit+"/$sam" }
	if($sendAsMbx -ne $null) {
		$sendAsMbx | % { $validSendAs+=$Mbx.Alias }
	}
}
Write-Host "Done!" -ForegroundColor "Yellow"
if($?){
Write-Host "`r`nSMTP Addresses" -ForegroundColor "Cyan"
	foreach($smtpadr in $localMbx.EmailAddresses){
		if($smtpadr.ProxyAddressString.SubString(0,5) -eq "smtp:") { Write-Host $smtpadr.ProxyAddressString.SubString(5,$smtpadr.ProxyAddressString.Length-5) }
	}
	Write-Host "`r`nAccess granted to the following mailboxes:" -ForegroundColor "Cyan"	
	$validAcl | % { Write-Host $_ }
	Write-Host "`r`nMailbox is allowed to send as:" -ForegroundColor "Cyan"	
	$validSendAs | % { Write-Host $_ }
}

Exchange et Powershell : définition de quotas en envoi et réception

Ayant récemment défini des quotas concernant la taille des mails en envoi et en réception afin de séparer une population standard et une population VIP, j'ai développé un script afin de traiter la population standard composée de plusieurs centaines de boîtes aux lettres.

La règle de transport posant la limite maximale, aucune boîte aux lettres n'avait de limite fixée individuellement. Ce script applique une règle de 10 Mo pour ces boîtes.

$UnltdMbx = Get-Mailbox -ResultSize unlimited | Where-Object { $_.MaxSendSize -eq "unlimited" -and $_.MaxReceiveSize -eq "unlimited" }
$UnltdMbx | % {
	echo $_.Alias
	Set-Mailbox $_ -MaxSendSize 10MB -MaxReceiveSize 10MB
}

Ensuite, si nécessaire, il faut ajuster la configuration globale du transport. Ici, la limite sera de 20 Mo.

Set-TransportConfig -MaxReceiveSize 20MB -MaxSendSize 20MB

De même, il est nécessaire de vérifier les tailles limites spécifiées dans les connecteurs et liens AD si nécessaire :

Get-ReceiveConnector | Set-ReceiveConnector -MaxMessageSize 20MB
Get-SendConnector | Set-SendConnector -MaxMessageSize 20MB
Get-ADSiteLink | Set-ADSiteLink -MaxMessageSize 20MB

En exécutant ces commandes, je permets donc aux utilisateurs standard d'envoyer ou recevoir des mails pesant jusqu'à 10 Mo, et aux utilisateurs n'ayant aucune limite de configurée d'envoyer ou recevoir des mails jusqu'à 20 Mo.

Plusieurs choses tout de même à retenir de cela :

  • La règle de transport sera toujours prioritaire sur un quota défini au niveau d'une mailbox.
  • Mettre un quota trop élevé peut se révéler contre-productif, puisque les serveurs de messagerie sont globalement configurés pour recevoir ou émettre des mails de 20 ou 30 Mo maximum. Si les mails sont trop volumineux en sortie, les destinataires ne les recevront jamais, soit bloqués par une solution anti-spam ou bien par le serveur de messagerie lui-même !
  • Les clients de messagerie ainsi que les quotas de boîte affectés ne sont pas conçus pour recevoir des mails de 50 Mo ou plus... il est bien important de s'assurer du bon dimensionnement des serveurs de mailbox et des quotas avant d'autoriser tout un chacun à envoyer des mails volumineux, bien que ça ne soit pas nécessairement une action courante... De nombreux systèmes existent de nos jours pour partager des fichiers lourds en passant simplement par un lien envoyé dans un mail ne contenant que du texte !

Naturellement, avant une application sur un environnement de production, il sera intéressant de tester sur un environnement de recette car l'on touche bien plus qu'un simple serveur de messagerie... Il est possible qu'il ait des effets de bord sur toute la chaîne de messagerie (relai SMTP, solution antispam / antivirus, liens réseau, stockage...)