Migration SharePoint 2007-2010

Transcription

LIVRE
BLANC
Migration SharePoint 2007-2010. Migration SharePoint 2007-2010. Migration SharePoint 2007-2010.
Migration SharePoint 2007-2010. Migration SharePoint 2007-2010.
Migration
SharePoint 2007-2010
Thomas Lathuilière
Responsable Opérationnel Netapsys
Responsable de l’offre SharePoint
[email protected]
02
Sommaire
1. Description de la problématique
03
2. Difficultés rencontrées
05
Utilisateurs déroutés face à la nouvelle ergonomie
05
Reprise des données faillible et pages non fonctionnelles
06
Fonctionnalités spécifiques hors service en 2010
07
as particulier : Passage de la version Enterprise
à la version Standard, ou Foundation
07
Cas particulier : Changement de domaine
08
3. Les considérations incontournables
10
Considérations Techniques
10
Considérations Organisationnelles
12
Considérations Humaines
14
Considérations Financières
14
4. Notre analyse
15
Prérequis techniques
15
Méthode : planning et disponibilité de la plateforme
18
Réalisation de la migration et reprise de données
19
Accès et sécurité
21
Apprentissage de la nouvelle plateforme
22
Aspect financier
22
5. Conclusion
23
6. À propos de Netapsys
24
Livre Blanc Data Discovery : Migration SharePoint 2007-2010 – Décembre 2011 - Tous droits réservés Netapsys ©
03
1.
Description de la
problématique
Lorsque nous utilisons une solution informatique au quotidien qui
s’appuie sur un progiciel, faire le choix d’une montée de version n’est
jamais trivial. Microsoft SharePoint n’échappe pas à cette règle.
En effet, nous sommes très fréquemment confrontés à la problématique
de faire évoluer des outils à un coût non négligeable, le tout pour une
amélioration des fonctionnalités à peine perceptible.
En ce qui concerne l’outil Microsoft SharePoint 2007, la montée de
version peut être motivée et déclenchée par différents facteurs :
• « Se tenir à jour » pour éviter qu’un écart trop grand s’installe entre la
version en production et les nouveaux standards du marché.
• Conserver un parc applicatif maintenu par l’éditeur.
• Homogénéiser les versions de l’écosystème Microsoft en place (Office,
Système d’exploitation…).
• Bénéficier des nouvelles fonctionnalités offertes par la nouvelle version.
• Faire face à une contrainte technique et/ou politique suite à une fusion
d’entités possédant des versions distinctes.
• …
Ceci étant, l’opération peut se révéler plus délicate qu’il n’y parait.
04
L’objectif de ce livre blanc est justement de passer en revue les différentes
difficultés à surmonter, les points de vigilance à garder à l’esprit
avant de se lancer dans l’upgrade, et enfin nos retours d’expériences
correspondants.
05
2.
Difficultés rencontrées
Utilisateurs déroutés face
à la nouvelle ergonomie
L’une des difficultés majeure survenant après une montée de version
en SharePoint 2010 est la capacité des utilisateurs à prendre en main
le nouvel outil. En effet, l’une des différences majeures entre les deux
versions concerne l’interface graphique et plus particulièrement
l’ergonomie de l’application.
Pour les concepteurs et les contributeurs, l’apparition du bandeau à la
mode « Office » vient complètement chambouler les habitudes prises.
Le concepteur SharePoint 2010 se retrouve alors autant démuni qu’un
utilisateur découvrant Microsoft Word 2010.
Par ailleurs, les visiteurs doivent également revoir leur manière de
naviguer dans les différentes pages et sites SharePoint. Le fil d’Ariane
complet disparait pour laisser place à un fil d’Ariane plus localisé et
fonctionnel (choix de la vue entre autres). Pour naviguer à travers
l’arborescence des sites, il convient d’utiliser le nouveau bouton
permettant de parcourir les différents niveaux.
06
Reprise des données faillible et pages
non fonctionnelles
La deuxième grande surprise concerne les liens cassés, les pages non
fonctionnelles et parfois même la mauvaise reprise des données.
Pour le premier point, en fonction de la méthode de migration choisie, la
nouvelle version de SharePoint peut se retrouver sur un nouveau serveur.
Si les liens hypertextes saisis dans la version antérieure de l’application
n’ont pas systématiquement été spécifiés en relatif, alors ces liens
continuent de rediriger l’utilisateur vers l’ancien serveur. Il faut donc
procéder à un remplacement global des mauvaises références.
Pour le second point des pages non fonctionnelles, il n’est pas rare de
naviguer sur un site nouvellement migré et de se rendre compte que des
pages auxquelles on tente d’accéder ne répondent pas. Les causes de ce
phénomène sont diverses : une WebPart référencée dans la page n’existe
plus en l’état dans la nouvelle version de SharePoint, une WebPart
visualiseuse de page est utilisée pour afficher le contenu d’un document
Word ou Excel, mais ce dernier est proposé en téléchargement dans la
version 2010, ou encore la page référencée à l’intérieur du composant
n’est plus accessible (CF. problématique précédente des liens morts).
Enfin, en ce qui concerne la reprise des données, pour peu que l’on
souhaite profiter de cette migration pour faire le ménage dans les
données, les déplacer, changer le domaine et donc les affectations
des documents, la tâche peut s’avérer particulièrement ardue et donc
faillible. Le résultat n’en sera alors que des plus approximatifs.
07
Fonctionnalités spécifiques
hors service en 2010
Lors d’une montée de version d’un progiciel, tout développement
spécifique qui a été réalisé afin d’enrichir la solution source doit
obligatoirement faire l’objet de tests et d’une nouvelle recette applicative
une fois migré.
Dans le meilleur des cas, le code fonctionne intégralement dans la
nouvelle version. Dans le cas le plus probable, le composant sur-mesure
est défectueux et nécessite une mise à jour.
Dans le cas particulier où il s’agit d’un composant spécifique acheté
à un éditeur tiers, il faut bien entendu vérifier auprès de cet éditeur
si le composant reste compatible avec la nouvelle version 2010 de
SharePoint, ou bien si le composant devra lui aussi faire l’objet d’une
montée de version.
Cas particulier : Passage de la version Enterprise
à la version Standard, ou Foundation
Lors d’une montée de version d’un progiciel, tout développement
spécifique qui a été réalisé afin d’enrichir la solution source doit
obligatoirement faire l’objet de tests et d’une nouvelle recette applicative
une fois migré.
Dans le meilleur des cas, le code fonctionne intégralement dans la
08
nouvelle version. Dans le cas le plus probable, le composant sur-mesure
est défectueux et nécessite une mise à jour.
Dans le cas particulier où il s’agit d’un composant spécifique acheté
à un éditeur tiers, il faut bien entendu vérifier auprès de cet éditeur
si le composant reste compatible avec la nouvelle version 2010 de
SharePoint, ou bien si le composant devra lui aussi faire l’objet d’une
montée de version.
Cas particulier : Changement de domaine
Indépendamment du type de gestions des utilisateurs et groupes dans
SharePoint, le changement de domaine est l’étape qui requiert la plus
grande vigilance et qui n’est jamais sans conséquence.
Lors du changement d’identifiants utilisateurs (login et/ou mot de passe),
une forte communication pour accompagner la gestion du changement
ainsi que des outils doivent être mis en place afin d’avertir l’utilisateur et
lui faciliter l’accès à la nouvelle plateforme.
Un des problèmes les plus récurrents suite à une migration, est le fait
qu’un utilisateur propriétaire ou auteur ne puisse plus avoir accès ni en
consultation, ni en modification à ses propres documents. Pour la simple
raison que son nouveau login ne dispose pas des droits nécessaires sur
l’ancien et/ou nouveau domaine.
Outre les problèmes d’authentification et de droits, lorsque l’ancien et
le nouveau domaine ne peuvent pas communiquer entre eux du fait de
contraintes techniques et/ou politiques, le changement de domaine lors
09
de la migration, peut engendrer dans ce cas des doublons au niveau des
groupes et utilisateurs dans SharePoint.
Et pour finir, après un changement de domaine, il n’est pas improbable
que des utilisateurs ne soient plus notifiés par mail des modifications
effectuées sur certains fichiers. En effet, si le changement de domaine
s’accompagne d’un changement d’email, il est nécessaire de reconfigurer
toutes les anciennes alertes définies.
10
3.
Les considérations
incontournables
Même si ce livre blanc aborde une problématique à priori purement
technique (migration d’un progiciel), il précise également l’importance
des composantes non techniques.
Considérations Techniques
La première considération technique concerne la date d’expiration de
la version SharePoint 2007 effective le 25/10/2012. Cette dernière est
fixée à 12 mois suivant la date du dernier Service Pack du produit (en
l’occurrence SharePoint Server 2007 Service Pack 3 sorti le 25/10/2011).
En termes de ressources matérielles, le prérequis incontournable
concerne l’architecture technique des serveurs ainsi que du système
d’exploitation qui doit être en 64 bits. Là où le choix du 32 bits était
encore possible avec la version 2007, elle ne l’est plus en 2010.
En ce qui concerne le nombre et le type de serveurs, la définition de la
topologie cible tenant compte des utilisateurs, de la qualité de service
ainsi que du niveau de disponibilité attendus permet de concevoir en
détail la configuration de la batterie de serveurs.
11
Pour le reste, RAM et CPU, le dimensionnement va fortement dépendre
du contexte et du nombre d’utilisateurs. Il suffit alors de se référer aux
recommandations publiées par Microsoft en matière de « sizing ».
Un autre point à ne pas sous-estimer concerne la définition et l’utilisation
des différents comptes techniques indispensables à l’installation et à
la configuration de SharePoint 2010. Même s’il est toujours possible
d’utiliser un même et unique compte technique, cela va à l’encontre de
n’importe quelle bonne pratique d’administration système.
SharePoint 2010 pousse alors le principe relativement loin puisque le
moindre service (recherche, accès à la base de données, Excel services…)
utilise un compte spécifique.
Vient ensuite le type de migration envisagé : « in place » ou « side by side
». Ce choix va fortement dépendre de la période d’indisponibilité que l’on
va s’autoriser.
Dans le premier cas, la montée de version est réalisée directement sur
l’environnement SharePoint 2007 en production. Pendant tout le temps
de la migration, le serveur sera indisponible. Dans le cas d’un problème
technique, la seule solution de retour arrière consiste à restaurer
l’environnement SharePoint 2007.
Dans le second cas, il convient de bloquer l’instance de la base
SharePoint 2007 en lecture seule, de dupliquer cette base de contenu sur
le serveur cible déjà installé vierge en version SharePoint 2010, puis de
réaliser la montée de version en attachant cette copie de base.
Enfin, la dernière considération à prendre en compte sur le plan
technique traite du contrôleur de domaine. En effet, par défaut la
12
migration SharePoint telle que prévue par Microsoft s’appuie sur
l’hypothèse que le domaine ne change pas. Dans ce cas, la migration
du contenu ne pose pas de problème particulier puisque la migration
revient à faire une mise à jour de schéma de base. Les utilisateurs, leurs
comptes, leurs habilitations et propriétés documentaires sont reportées à
l’identique.
En revanche, dès lors que la migration s’inscrit également dans une
modification de domaine, la situation se complique légèrement.
La solution préconisée va être de mettre en place une relation
d’approbation entre les deux domaines (l’ancien et le nouveau). Un
script de remplacement d’utilisateurs doit alors être joué afin de migrer
l’ensemble des utilisateurs de l’ancien vers le nouveau domaine.
Si cette dernière opération de mise en place de relation d’approbation
n’est pas possible (raison politique ou organisationnelle), il faut dans ce
cas s’orienter vers une reprise de données intégralement scriptée.
Considérations Organisationnelles
En ce qui concerne les processus métiers de l’entreprise liés à la
plateforme SharePoint, même si rien ne change d’une manière générale
entre les deux versions, il convient de profiter de la migration pour refaire
le point sur la couverture fonctionnelle de l’intranet ou de l’application
SharePoint, ainsi que de la situation sur les droits d’accès et les rôles de
chacun.
Une fois la migration effectuée, il convient de refaire une passe sur la
topologie afin de nettoyer la nouvelle version de tout site obsolète.
13
Notez que ce nettoyage aura pu être réalisé en amont sur la version à
migrer. Par ailleurs, la topologie (sites, navigation) peut être revue afin
d’améliorer la cohérence entre la plateforme et l’entreprise.
En fonction de la durée d’existence de la plateforme SharePoint 2007
dans l’entreprise, ainsi que de la rigueur employée dans la gestion des
droits, il est probable que la situation sur les habilitations ressemble à un
immense sac de nœuds.
Le passage à 2010 offre alors une excellente fenêtre de tir pour remettre
de l’ordre dans tout ça. Il convient dans ce cas de repartir d’une liste
nettoyée de groupes utilisateurs pour lesquels on repositionne les droits
au plus propre.
De manière transversale, la version 2010 de SharePoint offre une
ergonomie plus riche et de nouvelles fonctionnalités par rapport à la
version 2007. Cette migration est également le moment de positionner/
repositionner de nouveaux acteurs sur la plateforme cible :
• Propriétaires de sites
• Concepteurs
• Contributeurs
L’adhésion à la future application n’est que meilleure si les gens se
sentent impliqués.
14
Considérations Humaines
Même s’il ne s’agit que d’une montée de version, la conduite du
changement associée n’est pas à négliger.
La formation à l’outil permet de prendre en main les nouvelles
fonctionnalités ainsi que la nouvelle ergonomie. Cependant, il suffit que
la topologie soit modifiée pour perdre les utilisateurs s’ils n’ont pas été
prévenus.
Il est donc primordial d’accompagner les utilisateurs suite à une
montée de version afin de leur expliquer tout d’abord ce qui a motivé la
migration, puis ce qui implique que leurs compétences SharePoint soient
mises à niveau, enfin ce qui a été modifié lors du changement de version.
Considérations Financières
La dernière considération à prendre en compte est d’ordre financier.
Le responsable de la migration doit tenir compte des coûts suivants :
• Matériel afin de supporter la nouvelle plateforme (OTC-One Time Cost et
RTC-RunTime Cost)
• Licences logicielles
• Projet (MOA & MOE)
• Formation et Change Management
15
4.
Notre analyse
Prérequis techniques
Microsoft peut avoir tendance à sur-dimensionner les prérequis
technique nécessaires à la bonne exécution de ses environnements. Ceci
étant, il nous faut admettre que SharePoint est un produit gourmand en
ressource, avec un goulot d’étranglement notable dans l’accès à la base
de données sollicitée à outrance.
Nous pouvons donc conserver les préconisations de Microsoft comme
cible à atteindre (téléchargeable à cet emplacement : microsoft.com/frfr/download/)
Pour des déploiements de faible ampleur (extrait) :
16
Pour des déploiements sur des fermes (extrait) :
Concernant les outils de la suite Office qui s’intègrent de manière
optimale avec SharePoint 2010, il s’agit bien évidement de la version
équivalente, à savoir Office 2010. Les outils Office 2007 resteront
compatibles avec SharePoint 2010 mais dans une moindre mesure (par
exemple, la notion de co-authoring - édition à plusieurs en simultané n’est pas disponible avec Microsoft Word 2007).
Pour ce qui est du support des différents navigateurs web, le tableau
suivant résume les niveaux de prise en charge des navigateurs courants
(extrait sur site : technet.microsoft.com)
Pris en charge
Un navigateur « pris en charge » est un navigateur Web reconnu par
SharePoint Foundation 2010 et dont toutes les fonctionnalités sont
utilisables normalement. En cas de problème, le service de support peut
vous aider à trouver une solution.
17
Pris en charge malgré certaines limitations connues
Un navigateur « pris en charge malgré certaines limitations connues » est
un navigateur Web reconnu par SharePoint Foundation 2010, mais dont
le fonctionnement présente certaines limitations connues. La plupart
des fonctionnalités sont parfaitement utilisables et si l’une d’entre elles
ne fonctionne pas ou a été volontairement désactivée, la documentation
permettant de résoudre les problèmes est facilement disponible.
Non testé
Un navigateur Web « non testé » est un navigateur dont la compatibilité
avec SharePoint Foundation 2010 n’a pas été testée et dont l’utilisation
est susceptible de présenter certains problèmes. SharePoint Foundation
2010 fonctionnera de façon optimale avec les navigateurs Web mis à jour
et normalisés.
NAVIGATEUR
PRIS EN CHARGE
IE 8 (32 bits)

IE 7 (32 bits)

PRIS EN CHARGE
AVEC LIMITATIONS
IE 8 (64 bits)

IE 7 (64 bits)

IE 6 (32 bits)

Mozilla Firefox 3.6 (Os Windows)

Mozilla Firefox 3.6 (Os Windows)

Safari 4.04 (OS non-Windows)

Autre
NON TESTÉ

18
Méthode : planning
et disponibilité de la plateforme
Nous préconisons la migration « Side by Side » dans la majorité des
cas. C’est la méthode qui offre le plus de garantie de retour arrière avec
un minimum d’indisponibilité. La migration « In Place » est vraiment à
réserver pour des petites plateformes non critiques voir à des prototypes.
En termes de planning, il faut l’imaginer réaliste avec un peu de marge.
En effet, les temps de copie et d’opération de migration ne sont pas
négligeables et nous ne sommes jamais à l’abri de quelques mauvaises
surprises.
La première phase consiste à faire l’inventaire des fonctionnalités
utilisées par l’application source, et de dresser la cartographie précise de
la topologie à migrer. Cette définition de périmètre doit également inclure
l’exhaustivité des développements spécifiques qui ont pu être réalisés.
La deuxième phase dresse l’infrastructure cible et la positionne dans
le temps. Elle doit normalement déclencher un plan d’actions de
commande de ressources d’infrastructure suffisamment anticipé en
fonction des entreprises afin de tenir le planning.
Ce qu’il faut provisionner par-dessus tout est la phase de test. Cette
phase va permettre de valider l’effectivité de la migration. Ce sont aussi
ces tests qui vont permettre de s’assurer qu’aucune fonctionnalité
exotique ou développement spécifique n’a été omis lors de la phase de
définition de périmètre à migrer.
19
Réalisation de la migration
et reprise de données
La migration SharePoint ne pose pas réellement de problème à
proprement parler.
Depuis le Service Pack 2 de SharePoint 2007, Microsoft met à disposition
un script stsadm de diagnostic nommé « Pre-upgrade checker » intégré
à WSS 3 / MOSS 2007, il permet de valider la plateforme pour une
migration vers SharePoint 2010 (technet.microsoft.com/en-us/library/)
Une fois que les différents points en erreurs ont été adressés, que la
nouvelle instance de la base de données est configurée, que SharePoint
2010 est installé, il reste éventuellement à installer les templates
d’applications manquant, puis à migrer les bases de contenu.
20
Certains sites utilisent des templates initialement proposées par Microsoft
dans un pack additionnel destiné à WSS 3.0 et MOSS 2007. Sans action
de notre part ces sites restent non fonctionnels (erreur à l’accès). Pour les
rendre opérationnels, il suffit de redéployer les templates nécessaires (qui
heureusement restent compatibles avec SharePoint 2010).
L’opération stricte de migration consiste à détacher une (des) base(s) de
contenu d’une configuration 2007, pour les rattacher sur une installation
faite en 2010.
C’est lors de cette opération de ré-attachement de base de données que
la migration se réalise (mise à jour du schéma de la base de données au
format SharePoint 2010) :
Mount-SPContentDatabase WSS_Content_2007 -WebApplication
http://<new-serveur2010 –UpdateUserExperience.
Il convient ensuite de « réparer » et configurer un certain nombre
d’éléments qui n’ont pu être correctement migrés tels que les éventuels
liens invalides dans la « Quick Launch », les « Webparts » et les données
des listes et bibliothèques.
Il faut ensuite rétablir le mapping des accès de substitution étant donné
que le serveur hébergeant SharePoint 2010 est nouveau.
Par la suite, on prend soin de reconfigurer la plupart des services, tel que
le moteur de recherche et on re-planifie une indexation complète.
21
Cette « macro-procédure » ne tient pas compte des développements spécifiques. En effet, dès lors
que du développement spécifique a été déployé sur la plateforme 2007, aussi bien des WebPart
que du développement purement graphique (formulaires, master pages, javaScript, CSS…), il va
falloir s’assurer que le code reste compatible en version 2010.
Autant le dire tout de suite, la probabilité que la personnalisation graphique réalisée
spécifiquement pour un site SharePoint 2007 soit fonctionnelle sans modification en 2010 est nulle.

Pour ce qui est des WebParts, il est fort possible qu’elles restent fonctionnelles. Il faudra cependant
s’en assurer, et le cas échéant développer la mise à jour supportée par SharePoint 2010.
Remarque
Accès et sécurité
Par expérience, une plateforme collaborative qui vit connait
obligatoirement des dérives en matière de gestion de droits.
Il n’est pas rare de constater des droits qui sont mis en place au cas par
cas directement au niveau utilisateur, dans des sous-sites voir sur des
répertoires directement ou des documents.
Il en résulte une complexité accrue de la maintenance des droits d’accès.
Une montée de version représente le moment rêvé pour remettre de
l’ordre dans la gestion des droits. Non pas parce que SharePoint 2010
révolutionne le concept, mais simplement parce que l’on s’adresse
maintenant à une population d’utilisateurs aguerrie à la gestion des
droits, et qu’on lui donne la possibilité de repartir proprement ou tout du
mois de remettre de l’ordre.
Il est donc primordial de consacrer un peu de temps à cette phase.
22
Apprentissage de la nouvelle plateforme
La raison la plus fréquente des échecs ou difficultés remontées suite à
des migrations SharePoint est la sous-estimation de la conduite du
changement qui doit l’accompagner.
Il faut avoir conscience que SharePoint possède la réputation d’être
compliqué et peu intuitif. Les utilisateurs le voient comme un produit
d’informaticiens fait pour des informaticiens.
De plus, les modifications d’ergonomie entre la version 2007 et la version
2010 sont suffisamment importantes pour dérouter les utilisateurs sans
accompagnements. On pense notamment à la nouvelle notion de fil
d’Ariane, où tout le système de navigation a été revu.
Aspect financier
Pour ce dernier aspect, nous ne remontons pas forcément d’alertes si ce
n’est d’avoir en tête les coûts masqués ou indirects, tels que les licences
des produits associés nécessitant une montée de version (système
d’exploitation, suite Office, SGBD SQL Server…).
De la même manière, la formation et le support inhérent à cette montée
de version sont bien souvent sous-évalués (quand ils ne sont pas tout
simplement oubliés).
23
5.
Conclusion
Dans l’ensemble, une migration de Microsoft SharePoint 2007 vers
SharePoint 2010 se réalise simplement. Ceci est d’autant plus vrai lorsqu’il
n’y a pas de développement spécifique sur la version initiale.
En revanche, dès lors que la plateforme 2007 a subi plusieurs
spécialisations fines, il convient d’en profiter pour faire le tri lors de la
montée de version.
En ce qui concerne la conduite de changement, il ne faut pas la négliger
tant la nouvelle interface graphique est modifiée dans la version 2010 de
l’outil. Il est courant de comparer ce bouleversement avec celui induit
dans l’apparition du bandeau « Office » de la suite logicielle éponyme.
Enfin, cette migration apparaît incontournable si l’on s’inscrit dans
la durée avec cette plateforme Microsoft. En effet, la nouvelle version
SharePoint 2013 n’offrira pas de procédure d’upgrade à partir de la
version 2007, mais exigera de passer par une version 2010 intermédiaire.
24
6.
À propos de Netapsys
Netapsys est une société d’ingénierie informatique spécialiste des
nouvelles technologies (Java J2EE, Microsoft .NET, PHP, Javascript, ...).
Fondée en 2004 par deux experts des nouvelles technologies, Netapsys
a développé et cultive un savoir-faire unique de production logicielle.
S’inscrivant dans un principe d’amélioration continue, Netapsys capitalise
à la fois sur les hommes et sur un outillage avancé d’intégration continue
et de mesure permanente de la qualité de ses développements.
La société s’appuie sur sa capacité d’écoute et sur une veille
technologique de pointe pour apporter à ses clients PME, grands comptes
et services publics une prise en charge clés en main de leurs projets
applicatifs, ou de l’évolution de leur système d’information.
Netapsys vous accompagne sur toutes les solutions technologiques
créatrices de valeur pour les entreprises et institutions :




Business
Intelligence
E-commerce
Collaboratif
GED




Mobilité
Usines
logicielles
Ingénierie
logicielle
Web/CMS
25
Présente à Paris, Nantes, Lyon, Strasbourg et Madagascar, Netapsys
compte 350 collaborateurs et a réalisé en 2013 un chiffre d’affaires de
22 millions d’euros. Si vous souhaitez en savoir plus, ou tout simplement
nous rencontrer, n’hésitez pas à nous contacter [email protected].
Retrouvez également toute l’actualité de Netapsys sur notre site internet
www.netapsys.fr.
Netapsys Conseil
124-126, rue de Provence
75008 Paris
Tél. : +33(0)1 70 64 27 33
Netapsys Atlantique
17, rue Sanlecque
44000 Nantes
Tél. : +33(0)2 40 89 82 09
Netapsys Rhône-Alpes
18, rue Bourgelat
69002 Lyon
Tél. : +33(0)4 72 16 88 88
Netapsys Grand Est
11, rue de la Haye
Espace Européen de l’Entreprise
67300 Schiltigheim - Strasbourg
Tél. : +33(0)3 68 00 17 58
Netapsys Madagascar
Porte B22, Immeuble ARO Ampefiloha
101 Antananarivo
Tél : +261 20 22 552 99
[email protected]
www.netapsys.fr
blog.netapsys.fr

Migration SharePoint 2007-2010

Transcription

Documents pareils

Portail collaboratif - Grande Ecole - SharePoint 2007

Formation mise a jour office 2003 à office 2010 Paris,Institut

Développeur solutions métiers, Technologies

SharePoint 2016 - Concepteur - Fonctionnalités

NIMBUS TRAINING - Sharepoint utilisateurs 2 jours

Sharepoint 2013 - Concepteur avancé

Développeur SharePoint – Switzerland Mission