Connecter VSTS à Teams

Objectif

Avec Teams vous pouvez partager un ensemble d’information aux différents membres de l’équipe sans que ceci aille sur le site VSTS du projet.

Prérequis

  • Avoir un projet VSTS avec un backlog rempli (si ce n’est pas le cas vous pouvez créer un projet rapidement en suivant cet article)
  • Installer Teams

Suivre les événements du projet

Par défaut, VSTS notifie par mail différents évènements qui se produisent sur un projet. Par conséquent, notre boîte mail se retrouve vite saturée de mail provenant de VSTS.

Certains de ces évènements sont envoyés par défaut seulement à la personne qui a déclenché l’évènement.

Par exemple, suite au commit du code d’un développeur sur la branche de développement, l’échec ou la réussite du build automatique (cas d’une intégration continue) sera envoyé seulement à ce développeur, par défaut.

En connectant VSTS à Teams, ces différentes notifications peuvent être partagées à l’ensemble de l’équipe projet, sans encombrer les boîtes mail de chacun.

Etape1

Vous devez créer un nouveau canal à votre équipe projet sous Teams

  • Cliquer sur « Ajouter un canal », dans le menu contextuel de l’équipe

Teams1

Dans la fenêtre de création du canal :

  • Saisir le nom du Canal
  • Cliquer sur « Ajouter »

Teams2

Etape 2

Il ne reste plus qu’à créer un connecteur pour que les notifications de VSTS arrivent dans le canal Suivi Backlog.

  • Sélectionner le canal
  • Cliquer sur « Connecteurs » dans le menu contextuel

Teams3

Dans la fenêtre de gestion des connecteurs :

  • Rechercher « Visual »
  • Cliquer sur le bouton « Configurer » du connecteur Visual Studio Team Service

Teams4

Dans la fenêtre de configuration :

  • Sélectionner votre compte de connexion à VSTS
  • Sélectionner le nom de la souscription VSTS

Teams5_1

  • Sélectionner le projet à surveiller

Teams5_2

  • Sélectionner le type d’évènement à surveiller
    • Pour notre exemple : « Elément de travail mis à jour »

Teams5_3

  • Cliquer sur « Enregistrer »

Teams5_4

Lorsque la configuration est faite avec succès, le post suivant apparaît dans le canal :

Teams6

Etape 3

Vous pouvez tester le connecteur en modifiant par exemple une tâche du projet sous VSTS.

Teams7

Selon vos besoins, vous pouvez tester les différents types d’évènement que vous souhaitez écouter dans Teams.

Visualiser le Product Backlog du projet

Dans le canal dédié au projet, il est aussi possible d’ajouter un onglet afin de visualiser rapidement la backlog du projet sous forme de Kanban.

Etape 1

Dans le canal du projet :

  • Ajouter un nouvel Onglet, en cliquant sur « + »

TeamsBacklog1

Dans la fenêtre de sélection d’onglet :

  • Rechercher « VSTS »
  • Cliquer sur l’icône « VSTS »

TeamsBacklog2

  • Entrer vos identifiants de connexion pour VSTS

TeamsBacklog21TeamsBacklog22

Etape 2

Dans la fenêtre de configuration de l’onglet VSTS :

  • Sélectionner un compte de connexion à VSTS

TeamsBacklog3

  • Sélectionner la souscription VSTS
  • Cliquer sur « Continuer »

TeamsBacklog4

Etape 3

  • Sélectionner le projet
  • Sélectionner l’équipe
  • Sélectionner le niveau des items du Backlog à visualiser
  • Cliquer sur « Enregistrer »

TeamsBacklog5

Etape 4

Visualiser et partager avec votre équipe le kanban.

TeamsBacklog6

Attention, seuls les personnes possédant un compte pour se connecter aux projets pourront accéder à cet onglet.

 

Conclusion

Si vous utilisez déjà Teams pour gérer vos projet au sein de vos équipes, connecter VSTS à Teams est pratique. L’ensemble des informations dont vous avez besoin sont maintenant disponible sur un seul outil Microsoft.

Teams permet de visualiser rapidement et simplement certaines informations du projet VSTS, si vous avez besoin de plus de détail passer directement par VSTS.

 

 

 

 

 

 

 

Activating Office 365 groups is not an option

 I see a lot of different reactions when it comes to Office 365 groups. But there is one thing that unites close from every IT department I know : deactivate it, hide it ! (and pray for users to not get aware of its existence). Caricature ? Maybe

Reasons ?

  • We are not ready
  • We can’t control everything yet
  • We have difficulties matching every tool with a use case
  • We only want users to have the tools we decided they needed

Here is why those arguments are irrelevant in my opinion.

growefficiently-turntocloud

Everything is built upon groups

This is SaaS. Microsoft is deciding (with feedback from users of course) what the future is. And Microsoft decided the future will be built upon groups.

Lots of features have rolled out, some others are rolling out right now. And not only for first release customers. The only way to go back to good old SharePoint Sites : stop Office 365.

We are building technical debt

Technical debt is something we fight a lot as developers. Every problem, every bug that we just hide will come back one day. And it will be far more difficult to fix. We all know what happens when we shut down some work because we have other priorities. We will always have other priorities.

One day we will have to activate it,  whether there is no more ability to stop it or because no tool works without. And it is going to hurt. A lot.

This is the perfect moment to prepare

Features are rolling out, one by one. It is easy to stay tuned, news after news. We still have time. The perfect moment to try it. To get feedback from users. To check which tools we prefer for our usages. To build our adoption strategy. We may be surprised, as users may prefer groups to the big SharePoint template we spent months building.

All the time we spend creating SharePoint branding that will be obsolete in 6 months. All the energy we spend trying to hide O365 features. We could be monitoring usages, communicating, building adoption strategies, building tools to do what groups don’t do.

What’s wrong with giving tools to users ?

Everything that is rolling out now is just a set of extra tools users can have. Why so much hate ? It’s like IT departments want to tell people a list of scenarios with a tool attached to each one. We want to control everything. We are control freaks. There are reasons we build procedures, of course. But sometimes we should let go.

Maybe users know better than us what they need. Maybe they are used to massive tooling in there private life. Maybe they are now using Slack + Dropbox + Trello and have the same features but without you monitoring it. Maybe they just need a go and will be delighted to use those tools. Maybe not. The best way to know is to go for it, and get feedback. Feedback, iterative or lean strategies are not only for startups !

What is the worst case scenario ?

Users creating an important amount of groups, and information is not well organized ? Users creating groups they shouldn’t create ? Users uploading top secret documents in external groups ?

We can have power users with a global vision of the team and responsible for organizing work and data. Those people are already organizing other content in their team.

We can classify groups to remind users about what content should be in each group. We will soon be able to apply policies with each classification.

Users are adults with responsibility on their actions. We don’t block  every action that could be possibility dangerous if maybe someone was doing something very stupid. Or it is not yet the case in my country. We should stop doing that in IT every day, treating users as brainless children.

If you really need to ensure some documents will never ever possibly get out of your company, there are true solutions.

So what now ?

We don’t have to use everything now. We don’t have to love every feature. We don’t have to stop everything we had and migrate to groups. But we have to get used to them. And I think we will finally love using them.

Why and how we started contributing to Patterns & Practices

Our journey with Patterns & Practices

Our journey with Patterns & Practices started when we first saw the project on GitHub, maybe two years ago. We already had our own internal framework so we just checked what this new tool could do for us. It clearly didn’t cover all our use cases, and we would still have to use our own framework.

Then I came to Ignite in 2015, and I saw Vesa Juvonen presenting the provisioning framework. It was like “Damn, it has grown a lot!”. We started using it as nugget package. It was still not covering all our use cases, but we were migrating our code slowly. As a lot of people were using this project, we found PnP functions more tested than ours, and it was great. We still had our framework tho, but it was disappearing.

But we still had issues:
        We couldn’t debug when we had a problem
        We had to wait for fixes, so we copied PnP functions in our framework to fix them for ourselves
        We had to go to GitHub and browse files to understand fully all we could do with this framework

Contributing

And then, we decided to fork the project (we are using PnP-Sites-Core as a fork, as this is the project we use the most). When you know git (and I really recommend reading at least the first three chapters of the git documentation if you are new to it), it is really fast to set up your environment for development.

Our contribution workflow is:

contribution-patterns-practices

1.      We locally clone our fork
2.      When we want to do some changes, we create a branch for this change that we merge to master when it’s ready
3.      We have a dev branch, created from the tracked PnP-Sites-Core dev branch
4.      When we have something interesting to propose we create a branch, get the commits from our master branch and create the pull request

We then just have to regularly get updates from PnP repositories, and reference our fork as a submodule in other projects.

This new approach has some advantages:
        Our whole team has a better understanding of how the project works
        We can debug
        We don’t have to wait for official fixes
        We can add our own code directly into the framework
        It’s exciting to take part of a bigger community 

5 pull requests merged so far, and a 6th waiting 🙂

 

Gérer la mobilité des internes sur SharePoint (et autres), avec Azure AD Application Proxy

Dans un contexte de mobilité et BYOD, on désire de plus en plus ouvrir l’accès aux ressources « on premise » en dehors de l’entreprise. Si ADFS reste la référence pour l’ouverture aux externes, l’équipe Azure de MS a développé récemment un proxy applicatif permettant de se connecter en SSO  sans mise en place d’infrastructure ou reconfiguration de l’application « on premise ».

Votre application (ici un portail SharePoint) est tout simplement publiée comme une APP sur votre portail 365. L’authentification est transparente, en interne comme en mobilité.

On peut, bien sur, panacher avec ADFS pour les « vrais » externes qui n’auraient pas de compte dans un AD approuvé.

Le Principe

Dans le cas d’un utilisateur externe, on ne peut pas recourir à l’authentification intégrée sans VPN, et on recourt généralement à ADFS :

auth1

Si l’utilisateur externe (ou en mobilité) est référencé dans un annuaire AD, il existe une alternative à ADFS, présentée dans le cadre de ce post :

auth2

On évite ainsi :

  • De déployer ADFS
  • De recourir à un formulaire d’authentification ou autre custom provider

Le pré-requis est d’avoir synchronisé les utilisateurs avec notre tenant 365. On centralise alors l’authentification sur le tenant, et cette identitée « online » pourra être convertie en SSO en une identité interne via ce proxy applicatif.

Par exemple, dans le cas de l’authentification windows intégrée, « eissaly@mcnext.com » peut être utilisé comme « MCNEXT\Emmanuel.issaly »

Configuration 365

Si votre annuaire est déjà synchronisé avec azure AD (c’est un prérequis), Vous pouvez sauter ce chapitre. Sinon, créez un tenant Office 365 de test (un tenant de dev MSDN suffit)

image007

Créez une adresse admin facile à mémoriser, ici j’ai pris admin@eissaly.onmicrosoft.com

Sur ce tenant « eissaly », allez activer Azure AD par la tuile d’admin :

image008

Vous devez synchroniser les utilisateurs de votre domaine local avec un domaine online. Dans mon cas, mcnext.com étant déjà pris, j’ai ajouté un suffixe UPN « @clouddetest.fr » à mon AD de tests sp2013.local. Emmanuel ISSALY est alors identifié par SP2013\eissaly *ou* eissaly@clouddetest.fr.

Pour déclarer et vérifier le domaine clouddetest.fr dans azure, allez dans « Domains » du tenant 365 :

image009

Une fois le domaine vérifié, on peut lancer la synchronisation d’un serveur quelconque de notre lab avec ADCONNECT. C’est en fait un FIM customisé (au sens qu’il fonctionne correctement). Il vous faudra le compte admin 365 et le compte admin du domaine local.

Licences

Pour que l’application proxy fonctionne, il faut une licence Basic ou Premium AAD pour chaque utilisateur.
Activez le premium trial, ce qui vous donnera 100 licences.

image012

Publication de l’application SharePoint

Publication azure

 Nous allons publier notre SharePoint on prem comme une APP dans 365 :
Allons dans « Applications » de notre Azure AD, et faisons « ADD »

image013

image014

Puis s’offre à nous l’option de télécharger ce nouveau connecteur :

image015

Déployez-le sur un serveur 2012 R2 qui a accès à internet. Le serveur de synchro qui fait déjà AD connect est une bonne destination pour lui !

Suite à l’activation de ce connecteur, on a d’autres options dans la configuration de notre application :

1.- Une URL publique générique, ou l’adresse publique de votre domaine :

image017

image018

2. et la patte interne, en windows intégré :

image019

à noter que l’équipe azure AD travaille sans cesse à proposer de nouveau mappings, et l’on peut même maintenant convertir l’identité online à une identité non windows (via la délégation Kerberos)

Configuration HTTPS / Kerberos

Pour que cela marche, il faut quand même quelques contraintes, en l’occurrence une délégation contrainte Kerberos (KCD)

  1. Créer le SPN du portail (nom court nom long et compte de pool d’appli)

setspn –S http/portal sp_app

setspn –S http/portal.clouddetest.fr sp_app

2. Autoriser la délégation KCD sur le serveur qui héberge le connecteur :

Sur un contrôleur de domaine, Propriétés sur l’ordinateur, onglet délégation, autoriser la délégation :

image020image021

Puis ajoutez le SPN (on le trouve par le compte de pool)

image022

Vous devriez à présent obtenir un ticket kerberos en appelant votre site SharePoint.
Attention, il faut que le DNS appellé soit une IP (A record), pas un alias !

Synthèse

Le site SharePoint étant déclaré sur le tenant, on peut y accèder par un clic de tout périphérique connecté à Internet :

image023

De ce fait, que l’on soit à l’intérieur du LAN, ou d’un appareil mobile (ici Chrome + Android) connecté à office online, l’expérience utilisateur est maintenant la même, quelque soit l’environnement
(pas de prompt, Windows intégré dans notre cas)

image025

 Comment ça marche

Cf https://msdn.microsoft.com/en-us/library/azure/dn879065.aspx

image026

  1. L’utilisateur tape l’url du site SharePoint
  2. AAD proxy fait de la pré-auth : si vous êtes déjà connecté online, on obtient un jeton, sinon il vous prompte pour votre profil online.
  3. Dans tous les cas, le jeton obtenu est envoyé au proxy.
  4. Le connecteur extrait du jeton l’UPN (lidentifiant utilisateur)
  5. Le connecteur fait une demande de jeton Kerberos de la part de l’utilisateur
  6. Si la delegation est autorisée, le jeton est émis.
  7. Le connecteur envoie alors la requete et son jeton comme si on était “interne »
  8. La page est renvoyée au navigateur

Il est également possible de customiser le ticket kerberos pour que le login arrivant sur l’application ne soit pas l’email, ou soit un login différent du login online (typiquement pour se connecter à un système non Windows) :

image027

Sur ce schéma, je me connecte entant que joe@contoso.com à 365, mais j’arrive en tant que Contoso\joed sur l’application ciblée par ce connecteur.