Tijdelijk extra IT-experts nodig?

Sinds de eerste maanden van de pandemie hebben veel organisaties de overstap gemaakt naar het werken in Teams. Lange tijd was de focus daarbij volledig gericht op ervoor zorgen dat mensen thuis konden werken en toch met elkaar in contact konden blijven en vergaderen. Teams werd in een recordtempo uitgerold, en gebruikers maakten er vaak maar het beste van.

Inmiddels werken de meesten van ons weer in elk geval deels op kantoor. Veelal wordt er per team een afspraak gemaakt over wanneer er op kantoor gewerkt wordt, en onder welke voorwaarden. De behoefte aan het gebruik van Teams en in bredere zin Microsoft 365 blijft daarmee ongewijzigd groot.

Om gebruik te kunnen maken van Teams, is een goed ingerichte infrastructuur noodzakelijk. Bijvoorbeeld om te zorgen dat men zich kan aanmelden. Dit soort fundamentele aspecten is dan ook vrijwel altijd inmiddels geregeld. Wat echter niet altijd goed geregeld is, is governance. In deze blogpost beschrijf ik daarom vijf zaken waar je zeker over na moet denken en keuzes over moet maken om Teams niet alleen nu, maar ook in de toekomst beheersbaar en betrouwbaar te houden.

Keuze 1: Wie mag een nieuw Team aanmaken?

Of beter gezegd: wie mag een Microsoft 365 Groep aanmaken? Iedere Teams-omgeving is gebonden aan een M365 Groep. Zo’n groep is een verzameling mensen die met elkaar samen kunnen werken en daartoe een aantal hulpmiddelen krijgen aangeboden. In dit geval gaat het dus om een groep mensen die samen kunnen werken in een Teams-omgeving, bestanden kunnen opslaan in een SharePoint-omgeving, en gebruik kunnen maken van een gezamenlijke agenda en mailbox.

Figuur 1: M365 Groep en verbonden services

Het uitgangspunt van Microsoft is om het aanmaken van groepen via Teams (en de andere services) toe te staan aan iedereen binnen de organisatie. Hierdoor kunnen mensen gemakkelijk en zonder op IT te hoeven wachten zelf een nieuwe Teams-omgeving aanmaken.

Nadeel van deze aanpak is dat er een risico is op wildgroei, en dat het wellicht onduidelijk is waar nou precies welke informatie staat. Er kunnen dubbele groepen ontstaan, en er kan informatie worden verwijderd terwijl deze misschien gearchiveerd zou moeten worden. Kortom, het ontbreekt aan controle.

Er zijn diverse mogelijkheden om deze risico’s aan te pakken, maar een hulpmiddel dat veel organisaties nodig hebben is om het zelfstandig aanmaken van Groepen aan banden te leggen. Om dit te doen, maak je eerst een Beveiligingsgroep aan (in Azure). Vervolgens wordt er een PowerShell script uitgevoerd dat er voor zorgt dat alleen deze groep nog recht heeft om M365 Groepen aan te maken (zie deze pagina van Microsoft).

Keuze 2: Hoe gaan we om met naamgeving?

Wanneer je een nieuwe Teams-omgeving aanmaakt, wordt er op de achtergrond een nieuwe Microsoft 365 Groep aangemaakt. Deze Groep krijgt een mailadres met dezelfde titel. Dit maakt het mogelijk om een groep te maken met een naam die een ongewenst mailadres oplevert. Denk bijvoorbeeld aan een mailadres zoals finance@[organisatienaam] of directie@[organisatienaam].

Figuur 2: Naambeleid instellen

​

Je kunt dit voorkomen door gebruik te maken van voor- en achtervoegsels. Ga in Azure Active Directory naar Groepen en vervolgens naar Naambeleid. Hier kun je een voorvoegsel (prefix) of achtervoegsel (suffix) toevoegen. Deze kunnen gebaseerd zijn op een vaste tekenreeks (“M365-“ bijvoorbeeld) of op een dynamisch kenmerk. Resultaat is dat iedere nieuwe M365 Groep automatisch aangevuld wordt met de gekozen tekst.

Keuze 3: Hoe lang blijft een Team bestaan?

Een derde keuze is om vast te stellen hoe lang een Teams-omgeving kan blijven bestaan. Teams-omgevingen worden zelden actief opgeruimd, met als risico dat er op den duur een groot aantal verouderde en niet-gebruikte Teams blijft bestaan, waarvan niemand meer echt weet van wie ze zijn of wat de bestaansreden was.

Je kunt dit risico adresseren door een verloopdatum toe te voegen voor Microsoft 365 Groepen.

Ga naar Azure Active Directory > Groepen en kies voor Verloopdatum. Hier kun je de levensduur instellen. Meest gebruikelijk is een half jaar of jaar vanaf datum aanmaken.

Verloopdatum instellen

• in text
• center
• in text

Keuze 4: Welke compliance-tools heb je nodig?

De Teams-omgeving, net als de gehele Microsoft-365-omgeving, moet voldoen aan alle juridische en wettelijke normen die aan de organisatie gesteld zijn. Compliance helpt je om risico’s te verminderen rond gegevensbescherming en wettelijke normen. Dit alles regel je in het Compliance Center.

Belangrijke onderdelen:

• Preventie van gegevensverlies (DLP)
  Met de juiste instellingen en licenties is het mogelijk om het delen van gevoelige informatie te reguleren. Zo is het mogelijk om een waarschuwing te genereren wanneer een persoonsnummer of ander herkenbaar stuk informatie gedeeld wordt buiten de organisatie of dit zelfs geheel te blokkeren.
• Beleid rondom bewaren en verwijderen
  Wil je voorkomen dat gevoelige informatie vroegtijdig wordt verwijderd? Het is mogelijk om beleid in te stellen dat ervoor zorgt dat informatie voor een bepaalde tijd wordt bewaard, om het na die tijd definitief te verwijderen.
• Vertrouwelijkheidslabels
  Aan informatie wordt een label toegevoegd om de mate van vertrouwelijkheid aan te geven. Dit kan handmatig of geautomatiseerd, afhankelijk van de gebruikte licentie. Op basis van dit kenmerk kunnen allerlei beleidsregels worden uitgevoerd.
• eDiscovery
  Maakt het mogelijk om informatie te identificeren en verzamelen die kan worden gebruikt als bewijs in juridische zaken. De tool kan zoeken naar inhoud in Exchange Online, OneDrive voor Bedrijven, SharePoint Online, Microsoft Teams, Microsoft 365 Groepen en Yammer.

Keuze 5: Hoe gaan we om met externe toegang?

Tenslotte: wie mag er deelnemen in een Teams-omgeving of een meeting? Wie mag er bij je bestanden?

Je kunt dit regelen via Externe toegang en Gasttoegang. Externe toegang zorgt er voor dat externen kunnen deelnemen aan vergaderingen en chats. Gasttoegang geeft daarnaast toegang tot bronnen zoals Bestanden. Je vindt deze instelling in Azure Active Directory, het Teams-beheercentrum en het SharePoint-beheercentrum.

Activiteiten die uw gebruikers kunnen doen

Activiteiten die mensen van buiten uw organisatie kunnen doen

Conclusie

Wanneer je goed nadenkt over de thema’s die hierboven genoemd zijn, de juiste keuzes maakt en deze consistent doorvoert, maak je het mogelijk om veilig te werken met Microsoft Teams. Wil je graag dat iemand met je meedenkt over de beste keuzes voor jouw organisatie? Mijn collega-consultants en ik staan voor je klaar

Het lijkt vaak wel of er wekelijks nieuwe tools en frameworks uitkomen, en het is dan ook vaak keuzes maken als je bij wilt blijven.

Maar soms zijn er ook nieuwe ontwikkelingen die de kleinere beslissingen als kiezen tussen React of Vue overstijgen. Astro is zo’n ontwikkeling.

Wat is Astro?

Astro is een Static site builder, en dat is op zich niets bijzonders. Wat echter wél bijzonder is, is dat het Astro echt niets uitmaakt wat je in je Static site wil opnemen. Dus als je al een mooi navigatie-component hebt gebouwd in Vue, en een formulieren-component in React; het kan allemaal!

Astro is naast een builder eigenlijk ook een bundler, net zoals Webpack of Vite, maar dan heel erg slim. Zo is het mogelijk om een applicatie te bouwen met de bekende JavaScript-frameworks zonder dat er links naar de JavaScript-files nodig zijn. Je hoeft dan dus geen react.js in te laden, omdat deze al is gebundeld in het pakketje dat Astro voor je gemaakt heeft.

Inmiddels zijn er ook grote bedrijven die gebruik maken van Astro. Dit zijn onder andere Google, Trivago en Netlify.

Wat maakt Astro uniek?

Renderen

Voordat ik uit kan leggen wat Astro bijzonder maakt, moet ik iets uitleggen over Renderen. Hiermee wordt bedoeld: hoe (en waar) wordt de pagina in elkaar gezet?

Er zijn een aantal render-varianten mogelijk:

1. Client-side Rendering (de pagina wordt samengevoegd op het device van de gebruiker)
2. Server-side Rendering (de pagina wordt samengevoegd op de server en dan naar de gebruiker gestuurd)
3. Partial Hydration (de combinatie van de eerder genoemde varianten) de pagina wordt eerst geladen, en vervolgens wordt de inhoud ververst door nieuwere content)

Maar wat Astro nu onderscheidt, is dat het niet alleen mogelijk is om deze renderings-mogelijkheden toe passen per hele pagina, maar ook per eilandje (gedeelte van een pagina). Dit wordt dan ook wel Island Architecture genoemd. Stel je voor dat je op een homepage naast statische componenten als een header en een footer, ook informatie wilt tonen die dynamisch is en misschien langer duurt om binnen te halen. Een voorbeeld hiervan zie je in de afbeelding hieronder.

​Island Architecture

Astro heeft hier een specifieke syntax voor:

1. client:load Als een component wordt geladen zonder client attribuut, dan worden ze toegevoegd zonder JavaScript. Mocht je een component willen laden met JavaScript, dan is ieder geval een client:load noodzakelijk.
2. client:idle Voor componenten met lage prio. Deze worden pas gerenderd op het moment dat het initieel laden van de pagina klaar is.
3. client:visible een variant op idle, maat dan met lazy loading. Component wordt pas geladen wanneer het in beeld komt.
4. client:media Voor componenten die alleen zichtbaar zijn als een media query van toepassing is: bijvoorbeeld alleen op schermen smaller dan 400px.
5. client:only Zorgt er voor dat een component niet aan de server-side wordt gerenderd, maar alleen aan de client-side.

Wie zijn de concurrenten van Astro?

Concurrenten voor Astro zijn onder te verdelen in 2 groepen: frameworks en bundlers. In de eerste categorie zijn de grootste concurrenten waarschijnlijk NextJS en NuxtJS. Dit zijn vergelijkbare frameworks (NextJS op basis van React, en NuxtJS op basis van VueJS), die beiden mogelijkheden bieden voor Static Site Generation en Server Side Rendering. Het allergrootste verschil met Astro is dat:

1. Astro stelt je in staat te kiezen welk framework je wil gebruiken, of zelfs wil combineren
2. Partial hydration is bij Astro standaard. Bij andere frameworks is dit natuurlijk wel mogelijk maar niet direct out-of-the-box
3. Builds van Astro zijn doorgaans kleiner dan die van de concurrenten door een rigoureuze aanpak van JavaScript files.

Astro zegt in zijn documentatie ook nog het een en ander over het verschil tussen Astro en enkele andere alternatieven zoals

• Astro vs. NextJS of
• Astro vs. NuxtJS

Conclusie 🥁

Astro’s mogelijkheid om een applicatie te maken met JavaScript frameworks, die standaard wordt geleverd zónder JavaScript is verfrissend. Mocht je applicatie het wel nodig hebben dan laad je die gewoon in geef je die juiste client methode mee.

Zelf denk ik dat Astro heel interessant is. Juist omdat je verschillende frameworks kunt combineren, of via Astro als middenlaag stapsgewijs over kunt van het ene framework naar het andere. Astro groeit zowel in adaptatie door de Front-End community als in volwassenheid: Juni 2022 kom Astro uit bèta met de release van Astro 1.0.

In ieder geval; Ik houd Astro de komende tijd zeker in de gaten. Jij ook, en kan ik (of één van mijn collega’s) je helpen bij de implementatie? Laat het ons weten!