Bonjour,  
je suis en train de préparer une migration exchange de la version 2003 vers la version 2013. (en passant obligatoirement par 2010).  
 
Actuellement en exchange 2003, j'ai des utilisateurs qui partagent des BAL.  
User1: disposer d'une adresse user1@domaine.fr
User 2 à 4: ne disposent pas d'adresse mail, mais ouvrer la BAL user1@domaine.fr
 
Par contre, je ne suis pas certain que je puisse faire la même chose dans un exchange 2013. En effet je n'arrive pas à déléguer de droits pour la BAL user1@domaine.fr à des utilisateurs qui ne disposent pas d'adresse.  
 
Est-ce que vous avez déjà rencontré cela ?  
 
Merci d'avance

j'avais eu le me^me soucis, ce n'est plus possible.
faut que tu achéte des CAL exchange pour tes utilisateurs qui n'utilisent pas leur adresse mais qui utilisent des adresses de groupe.
ou alors tu ne fais qu'un compte AD pour tes X utilisateurs.. mais c'est une régression en terme de sécurité.
il faut favoriser l'individualité des comptes.

Mais pourquoi déjà migrer vers 2013 alors qu'il ne reste que 4 ans de support ? Avant vu que tu migres depuis 2003 qui n'a plus de support depuis 5 ans...
 
Et avec la RGPD tu ne peux plus permettre aux utilisateurs d'accéder aux données des autres façon open bar. Donc une personne = un compte AD = une BAL

Merci pour vos réponses.  

Le problème n'est pas tant les CAL que le fait de devoir créer des adresses mail pour des sessions qui n'en ont pas besoin.  
 

Etant donné que je pars d'une très ancienne version, je suis obligé de procéder par étapes. Techniquement il est impossible de faire une migration 2003 -> 2016 par exemple.  
Je suis donc dans l'obligation de passer par des versions intermédiaires. C'est pour cela que les étapes sont les suivantes:  
- 2003 -> 2010
- 2010 -> 2013
- 2013 -> 2016
 

Dans un mode parfait c'est ce que je ferais. Mais dans la réalité du terrain... c'est bien moins idyllique.  
 
Pour préciser un peu le contexte:  
Les utilisateurs du service A se connectent à un serveur RDP à l'aide d'une session générique. Depuis cette session générique les utilisateurs lancent l'application métier avec un nom d'utilisateur / mot de passe personnel. Ils disposent de plusieurs ordinateurs et donc de plusieurs sessions génériques pour accéder au serveur RDP.
Pour le service A nous avons une adresse e-mail, qui est consultée par tous les utilisateurs de ce service.  
Cette adresse est donc configurée dans plusieurs sessions génériques et les sessions qui accèdent à cette BAL n'ont pas d'adresse e-mail.
 
 

C'est pas du tout une bonne façon de travailler.
 
Tu créés une session et une BAL par personne, puis des BAL partagées pour chaque service, avec la délégation qui va bien. Ils se connectent au serveur RDP avec leur session perso, et ouvre l'application métier avec leurs identifiants perso.
 
Qu'ils disposent d'un ou de plusieurs ordinateurs n'a pas d'importance.
 
Tu essaies d'appliquer un modèle exotique (le kiosque), reserve à des cas ultra spécifiques, ça a ses limites. La migration est justement l'occasion de refondre tout ça, surtout que tu pars sur une triple (!) migration Exchange si j'ai bien compris.

Effectivement je pars pour plusieurs migrations.  
 
Et je suis complètement d'accord avec toi sur le fait que ce ne soit pas une bonne organisation.  
 
Malheureusement, dans les services nous avons énormément de turnover et donc des nouveaux utilisateurs toutes les semaines, pour des missions parfois très ponctuelles d'une journée ou quelques jours.  
Si je crée une session par utilisateur voici ce qui se passe:  
Dans le service A comportant plusieurs dizaines d'utilisateurs et ayant un fonctionnement 24/24 7/7, l'utilisateur 1 ouvre sa session. Lorsque l'utilisateur 2 va vouloir accéder au logiciel métier, il va lancer l'application mais sera toujours dans la session RDP de l'utilisateur 1 puisqu'il ne l'aura pas fermée.  
Même en essayant de les sensibiliser au fait de fermer la session lorsqu'ils ne sont plus devant le pc ils ne le font pas (et au passage vont se plaindre à la direction que cette organisation leur fait perdre du temps, qu'ils doivent taper le mot de passe pour se connecter au serveur et encore un nouveau mot de passe pour se connecter à l'application car elle ne peut être liée à notre AD et a donc une base de comptes propre au logiciel)  
On se retrouve donc dans le cas où la session personnelle de l'utilisateur 1 devient en fait une session RDP générique alors que nous voulions en faire une session personnelle.  
 
Sans la bonne volonté des utilisateurs, le système de session personnelle est donc quasi impossible à mettre en place.  
 
 
 
 

Mais comment ça se fait ça ? Il a accès au login/mdp de utilisateur 1 ?
 
Sinon tu peux mettre en place des comptes génériques, mais tu prend des risques.
 

Les autres utilisateurs n'ont théoriquement pas accès au mdp des autres.  
Mais si l'utilisateur 1 ouvre sa session, il y a de fortes chances qu'il ne la ferme pas, du coup les autres utilisateurs vont l'utiliser.  
J'ai tenté de contourner le problème en mettant un délai de déconnexion / fermeture de session au bout de 30 minutes. Malgré cela, le problème est toujours le même car en 30 minutes il y a presque toujours un utilisateur qui va utiliser le PC. J'ai donc voulu réduire ce délai et le passer à 10 ou 15 minutes. Seulement avec un délai trop court les utilisateurs me disent je n'ai pas le temps d'effectuer mes tâches et ensuite faire la saisie dans le logiciel je suis donc sans arrêt en train de me reconnecter.  
 
Pour recentrer un peu les choses et ma problématique:  
si je comprends bien, à partir d'exchange 2013 il n'est plus possible qu'une session ne disposant pas d'une BAL puisse ouvrir la BAL d'un autre utilisateur (dans le cas précis un BAL de service).  
 
Pour contourner cela, je vais probablement essayer de les faire se connecter à l'owa d'exchange pour qu'ils consultent la messagerie depuis le navigateur web.

Mais pourquoi une déconnexion ? Verrouille simplement la session via l'activation du savescreen par exemple.
 
Accessoirement, comme on t'a déja dit, tu es en train de truander Microsoft côté licence, donc c'est une raison de plus de mettre ta méthode tordue à la poubelle.

ledge01 OWA peu utiliser le SSO de la session active, il faudra que tu desactive cette fonctionnalité.
Donc tous tes utilisateurs, même ceux qui ont un adresse email devront s'authentifier sur leur messagerie... quelle perte de temps
ledge01 : met ton obligation de fermeture RDP dans ta charte.
Tu ne pourras jamais maîtriser par la technique toutes les boulettes des utilisateurs.
 
ledge01 on a eu le même probléme, en définitive nous avons fais un chéque a Microsoft.

 
Niveau truande de Microsoft côté licence, je ne pense pas. Je suis abonné à un contrat en fonction du nombre de postes qui me donne droit à toutes les version microsoft (windows serveur, office, exchange...) sans limitation.  
 

 
Mes utilisateurs ayant des sessions nominative utiliseront le client outlook, donc ils ne devraient pas avoir besoin de s'identifier.  
Le but serait de faire utiliser l'OWA uniquement pour les sessions génériques.  
 

Cette obligation elle y est dans la charte, malheureusement personne ne respecte.  
Je pense organiser prochainement une campagne de sensibilisation
 
Je ferais des tests avec l'OWA. Si c'est trop contraignant je verrais pour créer des adresses mail pour les sessions qui n'en ont pas besoin.  
Je pense que je "cacherais" ces mails dans le carnet d'adresse outlook pour que les utilisateurs continuent d'utiliser les anciennes adresses et ainsi avoir une méthode de diffusion identique à notre organisation actuelle.