évolution de votre solution sans VBS

a {
text-decoration: none;
color: #464feb;
}
tr th, tr td {
border: 1px solid #e6e6e6;
}
tr th {
background-color: #f5f5f5;
}Bonjour,Dans la perspective de la fin de vie annoncée du VBS (Visual Basic Script) par Microsoft, je souhaitais savoir comment vous envisagez l’évolution de votre solution.Koxo répond pleinement à nos besoins en milieu scolaire, et nous souhaitons continuer à l’utiliser dans les meilleures conditions possibles. Avez‑vous déjà étudié ou planifié une transition vers un autre langage ou un autre mécanisme d’automatisation pour remplacer les éléments reposant encore sur VBS ?Merci d’avance pour vos éclaircissementsCordialement,
Olivier

Bonjour,
Les scripts peuvent passer en PowseShell sans problème.
Pour le moment nous avions opté pour le VBS car plus léger et plus rapide à lancer (pas besoin d'attendre que le Framework soit chargé) et suffisant pour les tâches à réaliser.
Cdt
Le support

Bonjour,
J'ai commencé à voir pour adapter les scripts vbs en powershell.

Petit pré requis, penser à vérifier dans les GPO que l' exécution des scripts Powershell est autorisée sur les stations (c'est désactivé par défaut).

Pour info en ce qui concerne les mappages de lecteur réseau dépendants de variables telles que le(s) groupe(s) de l'utilisateur qui se connecte, il faut apparemment utiliser la commande net use disponible en Powershell car elle est la seule qui connecte vraiment le lecteur réseau et le rend visible/utilisable dans l'explorateur. Les autres commandes telles que New-SmbMapping ne rendent le lecteur réseau disponible que sous la session powershell sans apparaître dans l'explorateur de fichier, ou imposent d'autres limitations.

Dans le cas des dossiers de multiples  classes d'options, une solution simple semble de mapper non pas le dossier du groupe secondaire (classes) mais le dossier parent contenant toutes les classes et groupes d'options, et d'activer l'option"énumération basée sur l'accès" du serveur de fichier. Ainsi seuls les sous-dossiers auquel l'utilisateur a accès apparaissent dans l'explorateur.

Un exemple actuellement en test dans notre lycée :

# Unmap all existing drives
net use * /delete /yes

# Récupération des attributs du compte : lettre dossier perso,chemin dossier perso, groupe secondaire
$UserbObj = Get-ADUser -Identity $env:USERNAME -Properties * | Select homedrive,homedirectory,division
$homedrive=$UserObj.homedrive
$homedirectory=$UserbObj.HomeDirectory
$groupe=$UserObj.division

# Map Home Drive
net use $homedrive $homedirectory

# Map groups Drive
net use U: \\serveur\\$groupe$

exit

Bonjour,
Merci pour votre retour. 
Vos tests se passent bien  ?
Voici un exemple de script de groupe primaire : 
 
Cdt
Le support

Bonjour,
On a évidemment rencontré quelques soucis qui étaient plus ou moins prévus.
Pour l'instant seul un compte de test dispose de ce script en Powershell. Donc déjà il faut penser à renommer l'extension du script, car actuellement koxo génère un .vbs si on valide et applique le script à l'utilisateur.

-Notre petit script impose l'installation du module powershell active directory sur les stations (pour que l'instruction Get-ADUser fonctionne) , faisable qu'en élévation de privilège. On aimerait éviter de devoir rajouter des modules et que ça fonctionne avec la config des stations par défaut. De plus, même une fois le module installé, les variables ne sont pas toujours correctement récupérées et on ne sait pas trop pourquoi. Peut-être que les droits d'un compte utilisateur normal sont insuffisants pour faire une requete sur l'AD avec l'instruction Get-ADUser, même juste en lecture.

-De plus, bien que notre script soit ultra simple, il semble parfois mettre beaucoup de temps à s'exécuter, ce qui, sur des postes un peu anciens, est tout de même pénible. La lenteur disparait si on remet le script d'origine en vbs.

Merci pour votre modèle, ça va probablement nous aider .

Lorsque qu'on aura un script powershell fonctionnel, pensez-vous qu'il soit vraiment utile et/ou nécessaire de le signer pour paramétrer la sécurité d'exécution aux scripts signés uniquement ? Pour le moment pour les tests, on a autorisé tous les scripts locaux mais les distants doivent être signés.
 

Bonjour,
Le modèle ci dessus fonctionne en PowerShell 5.1 sans avoir besoin d'installer et d'importer des modules spécifiques.
Nos tests ont été fait sur une machine Windows 11 fraichement installée par défaut.
Le framework n'est pas chargé au départ et donc PowerShell l'attend pour fonctionner, avec le VBS ce problème n'existait pas, mais depuis les machines sont plus puissantes et ça devrait moins se sentir.
Cordialement.
Le support