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...)

Powershell : liste des serveurs sur lesquels un user est connecté

J'ai eu un incident concernant un lock de compte AD récurrent sur diverses stations. Afin de pouvoir déterminer sur quels serveurs était connecté ce login, j'ai développé un script Powershell qui parcourt un fichier CSV contenant une liste de serveurs (facilement générable à partir de l'ActiveDirectory).

Le script utilise l'application CLI win32 quser et prend en paramètre un nom de login d'utilisateur.

param([Parameter(Mandatory=$true)][string]$Login)
$serverlist = Import-CSV server-list.csv
foreach($server in $serverlist) {
	$qo = quser /server:$($server.Name) 2>$null
	if($qo -ne $null){
		$qo | foreach {
			if($_.Contains($Login)){
				Write-Host "Logged in on $($server.name)" -ForegroundColor "Green"
			}
		}
	}
}

Perte de connectivité LDAP après upgrade vCenter en 6.7 u3f

Cette semaine, j'ai été confronté à un incident plutôt particulier suite à un upgrade d'une appliance vCenter (6.5 vers 6.7 u3f - build 15976714). En effet, après l'upgrade, j'étais incapable de me reconnecter en utilisant mon login ActiveDirectory, pas plus qu'en utilisant un autre compte lié à ce même ActiveDirectory. Cependant, la connexion avec l'utilisateur local fonctionne bien.

Les vérifications de base ne donnent rien de particulier :

  • L'appliance existe bien dans l'ActiveDirectory en tant qu'objet Computer (je n'utilise pas de compte pour faire la connexion)
  • Les entrées DNS directes et reverse sont bien correctes

La sortie et réintégration à l'ActiveDirectory de l'appliance n'ont rien donné non plus, cependant il y a du mieux : tous les comptes renseignés en dur dans les autorisations globales peuvent ouvrir une session sur le vCenter. Cependant les comptes qui sont membres des groupes étant dans les autorisations ne fonctionnent toujours pas. De plus, l'appel aux webservices SOAP est toujours impossible par un compte sur l'ActiveDirectory (Veeam utilise ces webservices pour interagir avec le vCenter afin de sauvegarder les VM).

Étant donné le caractère plutôt urgent de la résolution de cet incident puisqu'il impacte les sauvegardes, nous avons contacté le support VMware qui nous a confirmé que ce dysfonctionnement pouvait arriver de manière aléatoire lors d'un upgrade de VCSA vers ce dernier build (6.7 update 3f) et que ce bug sera corrigé lors d'une prochaine release.

Malgré tout, le support ne nous a pas permis de trouver la cause du dysfonctionnement ; en faisant jouer nos réseaux, nous avons été mis sur la piste du fichier /etc/resolve.conf, que j'aurais dû vérifier en me connectant en SSH sur l'appliance (si je peux avoir une excuse, il était plus de 22h quand je me suis penché sur le sujet en urgence !).

Pour ce faire, ouvrir une session SSH sur le VCSA, puis saisir shell dans le prompt afin d'accéder au prompt standard de PhotonOS qui est le système d'exploitation socle de vCenter (basé sur GNU/Linux), puis saisir la commande suivante :

more /etc/resolve.conf

Cette instruction doit imprimer le contenu du fichier qui doit à minima contenir l'IP loopback et les DNS renseignés, ainsi que les zones DNS dans lesquelles chercher les enregistrements. Et c'est précisément ici que ça coinçait puisque notre zone ActiveDirectory n'était pas renseignée dans le paramètre search, alors qu'elle l'était sur l'ancienne appliance.

Une fois la zone ActiveDirectory renseignée et un redémarrage complet de l'appliance plus tard, la connexion avec des comptes LDAP était fonctionnelle et les sauvegardes opérationnelles.

Dysfonctionnements sur des partages DFS

Ces derniers jours, j'ai été confronté à un incident qui arrivait de manière complètement aléatoire lors de l'accès à des partages réseaux via DFS. Dans l'explorateur, un comportement erratique de celui-ci en naviguant dans les partages DFS, l'impossibilité de créer des répertoires ("une erreur réseau inattendue s'est produite"), la nécessité d'appuyer sur F5 pour voir le contenu d'un dossier ou encore l'impossibilité pour une application comme Excel d'écrire dans le chemin étaient des symptômes du dysfonctionnement.

Voici quelques caractéristiques :

  • Toutes les versions sur parc de Windows 10 sont concernées (1703, 1809, 1903)
  • De multiples serveurs de fichiers hébergeant les partages réseaux sont concernés
  • Les utilisateurs sont situés sur des emplacements géographiques différents et le dysfonctionnement est présent par connexion filaire, en WiFi ou via le VPN.

La recherche était d'autant plus compliquée pour isoler le dysfonctionnement que :

  • Aucun log n'était parlant ou utile sur les clients ou les serveurs de fichiers, pas plus que côté équipements réseau ou couche de virtualisation
  • Je n'avais aucun dysfonctionnement côté baie de stockage
  • Aucune modification n'a été faite côté infrastructure Windows / ActiveDirectory
  • Aucune campagne de patch n'a été réalisée avant l'apparition du bug.

Le travail n'a pas été facile car le problème étant complètement aléatoire et parfois résolu d'un simple F5 où d'un redémarrage, l'incident ne m'arrivait pas de suite et était généralement traité par les équipes support. Tous les serveurs étant sur le même hyperviseur, j'ai déplacé un ou deux serveurs sur un autre hôte : sans effet. Par chance, j'ai été très rapidement victime du dysfonctionnement, ce qui m'a permis de dégrossir l'incident et d'éliminer quelques pistes.

L'accès aux partages réseau DFS fonctionnait mal, que le lecteur soit monté sur un disque réseau ou un emplacement réseau ; à la main ou par GPO, aucune différence. Cependant, en accès direct en appelant le partage par le nom du serveur, aucun problème. Je n'ai rien relevé de particulier concernant la connectivité au serveur de fichiers en lui-même et les écoutes du réseau n'ont rien révélé de ce point de vue : j'étais donc quasiment certain qu'il s'agissait d'un problème au niveau de la couche DFS et non du partage de fichiers en lui-même.

J'axe donc mes recherches sur le DFS. Sur un poste qui rencontre le problème, une capture Wireshark est effectuée et je récupère les trames TCP qui vont enfin me permettre d'avancer. En effet, je vois régulièrement ces messages dans les trames TCP :

Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \dundermifflin.inc\SHARES\MSCOTT
Ioctl Response, Error: STATUS_NOT_FOUND

En cherchant un peu sur le web, je suis tombé sur des cas où un référent DFS a été créé et supprimé rapidement, entraînant un souci lors de la redescente des informations sur le poste de travail. Le poste de travail tentait alors d'interroger un référent DFS qui n'existait plus. Ce n'était pas mon cas, en utilisant l'outil dfsutil comme ceci, je n'avais aucune trace du mauvais référent :

dfsutil /pktinfo

Cette commande permet de sonder les référents DFS qui répondent aux requêtes DFS soumises par les postes clients. Je n'avais aucun référent caduc ni aucun code d'erreur particulier. En continuant de creuser avec mon tractopelle, je suis tombé sur l'outil dfsdiag qui allait me mettre sur la bonne voie.

dfsdiag permet d'effectuer des tests sur le bon fonctionnement de l'infrastructure DFS. Voici l'instruction que j'ai utilisé :

dfsdiag /testdfsintegrity /DfsRoot:\\dundermifflin.inc\SHARES /Recurse

J'ai donc bien une erreur concernant ce namespace :

Je teste sur un autre namespace pour lequel je n'ai eu aucun cas de remonté et qui est porté par des serveurs différents, et je n'ai pas ce message d'erreur.

Je recherche donc sur le net à propos de cette erreur et je tombe sur ce lien salvateur. Les namespaces DFS portés par un serveur doivent être enregistrés dans le registre ; il s'agit des clefs présentes dans l'arborescence Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\domainV2\. Dans le cas du serveur indiqué dans le message d'erreur, je n'ai rien, par contre sur un autre serveur du pool DFS, j'ai bien des clefs qui correspondent aux namespaces, avec pour chacune d'entre elles, deux valeurs de type REG_SZ (chaîne de caractères) LogicalShare et RootShare qui contiennent le nom du namespace en question (cachés sur la capture) :

J'ai donc procédé à la création des clefs et valeurs correspondantes sur le serveur incriminé, puis relancé le service DFS Namespace. En exécutant de nouveau dfsdiag, l'erreur a disparu et je n'ai plus eu de cas de dysfonctionnements d'accès aux partages DFS.