Si les nouvelles possibilités offertes par BlackBerry Enterprise Server (BES) 4.0 de Research In Motion (RIM) vous mettent l’eau à la bouche, vous planifiez probablement déjà votre mise à niveau ou migration. En règle générale, vous avez tout le nécessaire pour une transition facile. Néanmoins, avant de commencer, vous devez connaître certaines choses.Comme promis dans mon article « BlackBerry Enterprise Server 4.0 », je vais passer en revue les aspects importants de l’installation de la nouvelle version de BES et (à mon avis) sa nouvelle fonctionnalité la plus remarquable, appelée « wireless provisioning » ou approvisionnement sans fil.
Le passage au nouveau BES
Si vous n’avez jamais utilisé BES, vous devez effectuer un certain nombre d’étapes afin de préparer votre environnement à l’installation du produit. Il n’y a pas lieu de s’inquiéter ; le BES 4.0 Installation Guide détaille ces étapes, lesquelles incluent l’octroi au compte de service BES de privilèges de lecture et d’écriture au niveau des boîtes aux lettres des utilisateurs et la création de l’environnement de base de données nécessaire. Le passage à BES 4.0 à partir d’une version antérieure est également facile et bien expliqué dans le guide. Par conséquent, je ne vais pas aborder ces étapes ici. En revanche, je tiens à vous avertir : si vous avez plus que deux ou trois cents utilisateurs BlackBerry, en particulier si vous exécutez plusieurs instances du Redirecteur BES ou si vous avez plusieurs serveurs physiques, il ne suffira pas d’aller sur le CD-ROM et de commencer la mise à niveau. Il vous faudra avoir à l’oeil quelques problèmes potentiels.
Lorsque vous exécutez plusieurs instances du Redirecteur, chacune avec un nom unique et un identifiant RIM SRP (Server Routing Protocol), toutes ces instances seront regroupées sous un nom de serveur pendant la mise à niveau. Par exemple supposons que vous ayez quatre instances du Redirecteur : BES01A, BES01B, BES01C et BES01D. Après la mise à niveau, il ne restera que l’instance BES01A. Tous les utilisateurs affectés aux trois autres instances seront migrés vers la première.
Avant la mise à niveau, les informations de configuration dans chaque boîte aux lettres utilisateur contiennent des références aux noms de serveur individuels et aux identifiants SRP spécifiques associés à chaque instance. Supposons que les instances BES01A, BES01B, BES01C et BES01D utilisent respectivement l’identifiant SRP 1, 2, 3 et 4. Dans les versions précédentes de BES, le changement de nom de BES ou le déplacement des utilisateurs vers un nouveau serveur BES imposait aux utilisateurs de reconnecter leur terminal à l’ordinateur afin de recevoir les nouveaux identifiants SRP et noms de serveur requis pour restaurer la connectivité sans fil.
Pendant une mise à niveau vers BES 4.0, les identifiants SRP et noms de serveur sont déplacés vers Microsoft SQL Server ou la base de données de gestion BES MDSE (Microsoft SQL Server Desktop Engine), et BES continue d’utiliser « silencieusement » tous les identifiants SRP attribués précédemment. J’utilise le terme « silencieusement » car BlackBerry Manager et BlackBerry Configuration Panel (outils remplaçant la console MMC BlackBerry Enterprise Server Management) afficheront uniquement l’identifiant SRP pour le premier serveur : à savoir l’identifiant 1 associé à BES01A. En apparence, les identifiants 2, 3 et 4 ont été mis au rebut et ne sont plus employés. En réalité, BES met à jour lentement les terminaux, remplaçant ainsi progressivement les identifiants SRP 2, 3 et 4 par l’identifiant 1.
Les terminaux qui exécutent BlackBerry Handheld Software 4.0 reçoivent l’identifiant mis à jour immédiatement via la synchronisation sans fil. Les autres terminaux obtiennent le nouvel identifiant la prochaine fois qu’ils sont reconnectés à l’ordinateur. Cette méthode évite les interruptions de communications, mais vous devez être conscient que vous ne pouvez pas réutiliser immédiatement les anciens identifiants SRP pour installer un nouveau serveur. Si vous essayez de le faire, le réseau RIM SRP détectera que deux serveurs essaient d’utiliser le même identifiant simultanément et désactivera celui-ci. Tout terminal qui continue d’employer l’identifiant SRP concerné ne pourra plus communiquer. Dans ce cas, il faudra appeler RIM, leur expliquer humblement la situation et faire réactiver l’identifiant SRP.
Téléchargez cette ressource
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Travail hybride : pourquoi les salariés français restent les plus attachés au bureau en Europe
- Pourquoi la souveraineté des données relève du contrôle et non de la géographie
- L’incident OpenAI–Hugging Face n’est pas la révolution que vous imaginez
- Pourquoi les PME ne peuvent plus se permettre de négliger la sécurité de leur parc d’imprimantes
Articles les + lus
Travail hybride : pourquoi les salariés français restent les plus attachés au bureau en Europe
Cybersécurité : pourquoi 95% des violations de données sont liées à l’humain, surtout en été
Communication d’entreprise : la voix s’impose à nouveau comme canal critique à l’ère de l’IA
Asys accélère sur la planification intelligente avec l’acquisition de m-work
Communication d’entreprise à l’ère de l’IA : fragmentation, Shadow AI et perte de contrôle
À la une de la chaîne Mobilité
- Travail hybride : pourquoi les salariés français restent les plus attachés au bureau en Europe
- Cybersécurité : pourquoi 95% des violations de données sont liées à l’humain, surtout en été
- Communication d’entreprise : la voix s’impose à nouveau comme canal critique à l’ère de l’IA
- Asys accélère sur la planification intelligente avec l’acquisition de m-work
- Communication d’entreprise à l’ère de l’IA : fragmentation, Shadow AI et perte de contrôle
