O365 - Teknisk implementering

On-Premises Hardware / VM

Behov for on-premises hardware / VM’er i oppsett av Office 365 vil avhenge av flere faktorer:

  • Skal hybrid Exchange tas i bruk?
  • Skal hybrid SharePoint tas i bruk?
  • Skal on-premises Skype for Business tas i bruk?
  • Skal on-premises ADFS (AD federation service) tas i bruk?

Dersom svaret på en eller flere av disse er «ja» vil det være behov for on-premises hardware / VM’er.

I tillegg vil det være behov for en server som kan benyttes til provisjonere brukere til Office 365.

Istedenfor å ta i bruk on-premises hardware / VM’er kan en vurdere å ta i bruk en public cloud (IaaS).

Oppretting av Office 365 tenant

Valg av tenantnavn

Når en ny Office 365 tenant (også av noen benevnt ”instans”) lages vil denne få tildelt et unikt domenenavn på formen <tenant>.onmicrosoft.com.

Det er viktig å bemerke seg at Microsoft ikke per i dag har noen support for å endre tenant-navn. Det er derfor lurt å tenke grundig igjennom hvilket tenant navn som er ønskelig. Dette tenant-navnet vil for eksempel bli synlig i alle SharePoint Online URL`er.

Eksempelvis dersom en tenant med navn ”stud<institusjon>.onmicrosoft.com” lages vil en være bundet til dette navnet også dersom en på et senere tidspunkt finner ut at ansatte skal benytte samme tenant som studentene.

Bedrifter, kommuner og institusjoner fusjoneres/endrer navn sett over et lengre tidsperspektiv. Sett i lys av dette kan en vurdere å opprette en tenant med et tenantnavn som er «uavhengig» av institusjonsnavnet, for å potensielt unngå å havne ut med et tenantnavn som ikke stemmer.

Ansatte og elever/studenter i samme tenant

For en undervisningsinstitusjon vil samhandling mellom ansatte og elever/studenter være viktig. Samtidig vil det være ønske om å kunne sette sikkerhetssperrer mellom ansatte og elever/studenter. Det være seg oppslag i kataloger eller tilgang til dokumenter/web-områder i Office 365. Ved å opprette en tenant for ansatte og en annen tenant for elever/studenter vil en oppnå høy kontroll på sikkerhet, men dette vil påvirke evnen til å samhandle i så stor grad at det ikke vil være anbefalt.

Anbefalingen vil være å opprette en tenant som inneholder både ansatte og elever/studenter. Sikkerhetssperrer mellom ansatte og elever/studenter kan bygges inn på et annet nivå.

Opprette tenant

Opprett gratis 30-dagers prøveperiode:

https://portal.office.com/Signup/MainSignup15.aspx?Dap=False&QuoteId=79a957e9-ad59-4d82-b787-a46955934171&ali=1

Alternativt gå til https://www.office.com, klikk på "prøv det gratis for bedrifter".

Et tips kan være at denne brukeren som opprettes her lages som en administrator-bruker. For eksempel admin@.onmicrosoft.com. Denne brukeren vil bli tilordnet «Global administrator» (Company Administrator) rollen. Superbruker/root-bruker i Office365.

Kontakt Crayon for å knytte dine Campus-lisenser til opprettet tenant. Alternativt når prøveperioden er i ferd med å gå ut gå til:

https://portal.office.com/AdminPortal/Home?switchtomoderndefault=true#/cataloghttps://portal.office.com/AdminPortal/Home?switchtomoderndefault=true#/catalog

Kjøp ønsket type lisens.

For å være berettiget til å kjøpe lisenser basert på «Planer for utdanning» (educational pris) vil du først måtte knytte ditt domene inn i tenanten som er laget. Deretter når du utfører et kjøp av en slik type lisens (For eksempel «Office 365 Education for fakultet») vil Microsoft gjøre en avsjekk/ verifisere at ditt domene er berettiget til educational prising.

AzureAD (Azure Active Directory)

Når en ny Office 365 tenant lages vil denne automatisk bli knyttet til / få opprettet en AzureAd. AzureAD er brukerdatabasen til Office 365 (En felles brukerdatabase for Azure, O365 og Intune).

https://azure.microsoft.com/nb-no/documentation/articles/active-directory-whatis/

Tilgang til AzureAD nås via Office 365 Administrator -> Administrasjonssentre -> Azure AD

Eller via PowerShell:

https://msdn.microsoft.com/en-us/library/JJ151815.aspx

Azure AD Premium

Azure AD Premium er en versjon av Azure AD med utvidet funksjonalitet:

https://azure.microsoft.com/nb-no/documentation/articles/active-directory-editions/

Azure AD Premium er ikke inkludert i lisens for Office365 og må derfor om ønskelig kjøpes i tillegg, enten som frittstående lisens eller bundlet som en del av Enterprise Mobility Suite (EMS), som inkluderer blant annet Intune (Mobile Device Management).

For Office 365 vil Azure AD Premium utvidet funksjonalitet i forhold til:

Funksjonalitet som kan være interessant for utvalgte Office 365 brukere med høye sikkerhetskrav.

Knytning til institusjonens domene

Alle brukere i tenanten som er opprettet vil få en epost-adresse på formen <bruker>@<tenant>.onmicrosoft.com (dersom Exchange lisens tilordnes). Normal vil det være et ønske om å kunne koble brukerne til institusjonens reelle domenenavn / mail-domene / sub-domene.

Før «Provisjonering av brukere til Office 365» gjøres vil det være en forutsetning at Office 365 tenanten konfigureres til å knyttes til institusjonens domene. Uten dette vil ikke brukere med UserPrincipalName på formen <brukernavn>@<institusjon>.no kunne provisjoneres. «Føderert pålogging ved bruk av FEIDE» vil også forutsette at knytning til institusjonens domene er utført.

Knytning av Office 365 tenanten til institusjonens domene vil også være en forutsetning for å kunne få kjøpt lisenser i Office 365 basert på «Utdannings-priser».

Ved bruk av Administrasjonssenteret

I «Administrator modulen» -> Innstillinger -> Domener

Klikk «Legg til domene»

Skriv inn domene du ønsker å knytte til Office 365, for eksempel <institusjon>.no -> Klikk Neste

Sør så for å få lagt disse DNS innslagene inn under ditt DNS domene. I påvente av å få utført denne jobben kan du trykke «Lagre og Lukk». Når dette er aktivert i DNS kan du så åpne denne på nytt, klikk «Start Konfigurasjonen» -> Bekreft

En vil så bli guidet gjennom valgfrie steg for oppsett av slikt som ruting av mail til Office365 og Skype for Business. Her bør en ikke gjøre noe før en har planlagt dette mer i detalj.

Ved bruk av PowerShell

Knytning av domene til Office 365 kan også gjøres ved bruk av PowerShell:

https://jaapwesselius.com/2015/05/06/manage-domains-in-office-365-using-powershell/

Provisjonering av brukere til Office 365

Provisjonering av brukere til Office 365 vil si å ”speile” en lokal brukerdatabase til Office 365 sin brukerdatabase AzureAD, slik at Office 365 får brukerobjekt med attributter som gjenspeiler brukerne som er tenkt å logge på.

Klargjøring / vasking av lokal Active Directory (AD)

Dersom lokal brukerdatabase er Microsoft Active Directory kan det være behov for å klargjøre den før første synkronisering av brukere til AzureAD gjøres.

Office 365 IdFix:

https://support.office.com/en-us/article/Install-and-run-the-Office-365-IdFix-tool-f4bd2439-3e41-4169-99f6-3fabdfa326ac

Ved behov endre UPN suffix (ved for eksempel bruk av .local AD domain):

https://support.office.com/en-us/article/How-to-prepare-a-non-routable-domain-such-as-local-domain-for-directory-synchronization-e7968303-c234-46c4-b8b0-b5c93c6d57a7

ImmutableID / SourceAnchor

Som en del av planleggingen med å provisjonere bruker til Office365 er det viktig å ha en forståelse for konseptet «ImmutableID». «Immutable» betyr «kan ikke endres», noe som indikerer en advarsel om at dette er noe som bør planlegges nøye. At «ImmutableID» ikke kan endres er ikke helt sant (PowerShell kan brukes til å justere ImmutableID), men med et stort antall brukere vil det være en stor jobb og kreve betydelig nedetid.

«ImmutableID» er en nøkkel/identifikator som benyttes for å mappe elementer mellom lokal brukerdatabase (ActiveDirectory/LDAP) og Office365 sin brukerdatabase AzureAD.

Mens AzureAD/O365 benytter «ImmutableID» som betegnelse, omtales «ImmutableID» i ActiveDirectory / Azure AD Connect som SourceAnchor (CloudSourceAnchor).

Det er flere elementer å ta hensyn til når en velger hva en skal benytte som «ImmutableID».

Active Directory «objectGUID» (default) som «ImmutableID» er ikke en god løsning dersom brukere eksisterer i mer enn et AD forest. Det vil også kunne skape problem dersom det blir behov for å migrere brukere til et nytt AD forest (som for eksempel ved sammenslåing av institusjoner/organisasjoner/avdelinger). Alt som gjør at «objectGUID» for en bruker kan endre seg gjør dette til et dårlig valg som «ImmutableID».

  • Brukere endrer navn når de for eksempel gifter seg/skiller seg. Derfor vil brukernavn være et dårlig valg som «ImmutableID». Det er også en av grunnene til at @-tegnet (brukt i epost-addresse) ikke er gyldig tegn i «ImmutableID».
  • Det kan også være innleide eller midlertidige ansatte en må ta hensyn til når «ImmutableID» velges. For eksempel kan det være disse ikke får en «Ansatt ID» og at derfor valg av «Ansatt ID» som «ImmutableID» er uheldig.

En mulighet kan være å vurdere bruk av en Active Directory «Extension Attribute» for å kontrollere / ta hånd om en egendefinert «ImmutableID».

Ved konfigurering av føderert pålogging ved bruk av FEIDE, direkte SAML2.0 AzureAD -> FEIDE, er det et krav om at ImmutableId settes lik FEIDE UID (Bruker-ID). Bakgrunnen for dette ligger i Microsoft sin implementering av SAML2.0 der de sier «NameID - The value of this assertion must be the same as the Azure AD user’s ImmutableID».

Valg av UserPrincipalName (UPN)

Office 365 benytter AzureAD UserPrincipalName attributten til å identifisere brukere når pålogging til Office 365 utføres.

Se «Azure AD sign-In»:

https://azure.microsoft.com/nb-no/documentation/articles/active-directory-aadconnect-design-concepts/

  • Skal være på formen «brukernavn@domene»
  • Forutsetter at «Knyttning til institusjonens domene» er utført

«Direkte SAML2.0 AzureAD -> FEIDE føderert pålogging» forutsetter at UPN (UserPrincipalName) settes lik FEIDE eduPersonPrincipalName (https://www.feide.no/attribute/edupersonprincipalname)

Se AzureAD brukernavn avgrensninger:

https://azure.microsoft.com/en-us/documentation/articles/active-directory-passwords-policy/

Installasjon og konfigurasjon av Azure AD Connect

Azure AD Connect er det anbefalte verktøyet å benytte til å provisjonere brukere til Azure AD (Office365).

https://azure.microsoft.com/nb-no/documentation/articles/active-directory-aadconnect/

Automatisering av konfigurasjon i Office 365

I et større produksjonsmiljø vil det være behov for å automatisere konfigurering av elementer i Office 365. Typisk vil det kunne dreie seg om:

  • Tilordne lisenser til provisjonerte brukere
  • Aktivere arkivering på brukernivå
  • Sette språkinnstillinger på brukernivå

Dette kan oppnås på flere måter:

Beskrivelse på hvordan en kan benytte ”Azure Automation” finnes her:

https://azure.microsoft.com/nb-no/services/automation/

"Azure Automation" gir en høytilgjengelig platform spesiallaget for kjøring av PowerShell script. En fordel med å benytte «Azure Automation», fremfor å lage et lokalt powershell script som kjøres jevnlig, er at du her slipper å skrive inn passord i klartekst i scriptet, noe som ikke er optimalt.

Denne metoden forutsetter lisens/tilgang til Microsoft sin sky-tjeneste «Azure». Dette er ikke en del av Office 365 lisensen.

https://github.com/UNINETT/azure/blob/master/modules/azure_automation_accounts.md

Føderert pålogging ved bruk av FEIDE

En kan oppnå føderert pålogging ved bruk av FEIDE på flere måter:

  • Direkte SAML2.0 tilkobling mellom AzureAD og FEIDE
  • Oppsett av ADFS server(e). Kan settes opp lokalt eller i skya som VM'er
  • UH-AD sin ADFS løsning

Disse og flere alternativer finner en her:

https://www.linkedin.com/pulse/office365-authentication-higher-education-norway-andreas-solberg

Direkte SAML2.0 AzureAD -> FEIDE

Dersom en ikke har noe Microsoftkompetanse i egen organisasjon eller ikke ønsker/trenger ADFS som en ekstra komponent mellom AzureAD og FEIDE kan direkte kobling mellom AzureAD og FEIDE være en løsning. Dette er på nåværende tidspunkt en pilot-tjeneste.

Forutsetninger er:

Når disse forutsettningene er implementert. Logg inn på Feide kundeportal for å finne din org-id.

Gå deretter til: https://proxy.feide.no/idp/<org-id>/azureconfig

Logg på din organisasjons Office 365 tenant med powershell (v1) og aktiver den konfigurasjonen du får listet ut på denne siden.

Når dette er gjort skal en etter en liten stund kunne logge på Office 365 ved bruk av FEIDE.

Begrensninger

  • Løsningen støtter ikke SAML ECP (Enhanced client or proxy)
  • Brukere som har mailklient som kun støtter POP/IMAP må aktivere MFA (Multifactor authentication), for å få tilgang til "application password" som de kan benytte for å konfigurere mailklienten.
  • Løsningen støtter ikke FEIDE initiert logout (SLO). Det vil si at en ikke fra FEIDE siden kan initiere en logout på Office 365.
  • Av pilotbrukere er det rapportert utfordringer rundt Active Sync.

Pilotbrukere

ivan.rasen@atea.no har implementert denne løsningen hos to av sine kunder.

Kontakt rune.myrhaug@uninett.no ved spørsmål ut over dette.

Lokal ADFS

Dette er den mest brukte løsningen for oppsett av føderert pålogging ved bruk av FEIDE i UH-Sektoren per i dag. Oppsett og installasjon av en lokal ADFS løsning vil kreve lokal kompetanse på Microsoft AD/ADFS i egen organisasjon og/eller benytte bistand fra konsulentselskap.

I et produksjonsmiljø, med behov for høy tilgjengelighet, vil en ADFS implementasjon medføre behov for 2 x ADFS server + 2 x Web Application Proxy servere.

Dette kan for eksempel settes opp i Azure:

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-azure-adfs

Eller en kan sette opp lokale VM’er/Servere til dette formålet.

Guide på installasjon av ADFS:

For å få FEIDE pålogging vil en ha behov for å legge inn «idp.feide.no» som en ekstra «Claims Provider Trust».

Kontakt kontakt@uninett.no for å få satt opp nødvendig konfigurasjon på FEIDE-siden.

Federation metadata address (host name or URL):

https://idp.feide.no/simplesaml/saml2/idp/metadata.php/FederationMetadata/2007-06/FederationMetadata.xml

Endre «Secure hash algorithm» til «SHA-1» (Open Properties -> Advanced)

På denne «Claims Provider Trust»’en konfigurere opp Claim-Rules for å matche FEIDE attributter med AD attributter.

eduPersonPrincipalName -> UPN
c:[Type == "eduPersonPrincipalName"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Value = c.Value);
					
mail -> emailaddress
c:[Type == "mail"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Value = c.Value);

http://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0-higher.aspx

UH-AD ADFS

IT-Avdelingen ved Universitetet i Oslo (USIT) leverer UH-AD som en fellestjeneste til sektoren. Gjennom tilkoblet ADFS til UH-AD leveres føderert pålogging ved bruk av FEIDE som en tjeneste.

https://www.feide.no/tilgjengelige-tjenester?id=2037820

https://www.uninett.no/uh-ad

Smartlink

Istedenfor å gå til URL https://portal.office.com, for så å skrive inn ditt brukernavn, for så å bli videresendt til føderert pålogging, er det mer naturlig å skrive inn en URL som tar deg direkte til føderert pålogging (eller inn i O365 dersom du allerede er pålogget).

Overordnet fungerer SmartLink slik:

  • Bruker skriver inn en URL, for eksempel http://o365.<institusjon>.no
  • DNS inneholder et A record (eller CNAME) som videresender o365..no til en web-tjener som er satt opp
  • Denne web-tjeneren inneholder igjen en 302 redirect til din institusjons URL for innlogging til portal.office.com via FEIDE.

Dersom en følger beskrivelse for oppsett av «Direkte SAML2.0 AzureAD -> FEIDE» gjør følgende:

  • Denne beskrivelsen tar utgangspunkt i at du har tilgang til en Azure Subscription med mulighet til å opprette en «Azure App Service». Dersom du ikke har dette er det mulig å publisere til en IIS

https://github.com/UNINETT/office365/blob/master/documentation/o365-smartlink.md

Bytt ut redirectUrl definert i:

https://github.com/UNINETT/office365/blob/master/code/o365SmartLink/src/o365SmartLink/Startup.cst

Der uninett.no byttes ut med ditt domene.

Ved bruk av annen føderert påloggingsmekanisme (Slik som ADFS) se for eksempel:

Backup / Arkivering

Slettede elementer ligger i papirkurven i 30 dager og blir deretter fjernet permanent hos Microsoft. Dette må sees mer på som en disaster recovery løsning enn backup. Det finnes tredjepartsprodukter dersom man ønsker en mer fullverdig backupløsning. Eksempler på leverandører er Veeam, Cloudfinder, Spanning (Dell EMC) og AvePoint.

Arkivering:

https://technet.microsoft.com/en-us/library/dn790612.aspx

Office 365 grupper

Office 365-grupper er en funksjon som er utviklet med samarbeid i tankene. Standarden er at alle brukere kan opprette grupper etter eget ønske. Dette kan føre med seg uheldige konsekvenser i et større produksjonsmiljø. For eksempel kan personer lage grupper med gruppenavn som det er ønskelig å reservere til mer kontrollerte/formelle formål. Det finnes derfor en rekke mekanismer for å kontrollere oppretting av Office 365 Grupper.

https://blogs.office.com/2016/06/13/whats-new-in-office-365-groups-administration-june-2016-update/

Kontrollere hvem som kan opprette O365 grupper

ToDo

Prefiks

Dersom det tillates at hvem som helst skal kunne opprette en O365 gruppe vil det ofte være ønskelig å sette en prefiks på gruppenavnene som lages (adhoc), for å unngå at grupper lages med gruppenavn som det er ønskelig å ha kontroll på.

Per 01.06.2016 er metoden for å styre dette ved bruk av «Create a distribution group name policy»

https://technet.microsoft.com/en-us/library/jj218693(v=exchg.150).aspx

http://www.wictorwilen.se/office-365-groups-for-admins-group-creation-policies

Denne metoden fungerer kun innenfor «Exchange Online». Det betyr at dersom for eksempel en gruppe blir opprettet i «Office 365 Planner» vil ikke denne gruppen få den satte prefiksen. Microsoft jobber med å få på plass «Naming policy in Azure Active Directory» som vil løse dette.

https://thoughtsofanidlemind.com/2016/06/07/controlling-the-creation-of-office-365-groups-using-an-azure-active-directory-policy/

Multidomain

Når en gruppe opprettes vil gruppen automatisk få tildelt en epostadresse på formen <gruppenavn>@<tenant>.onmicrosoft.com

Ofte vil det heller være ønskelig at grupper opprettes med for eksempel epostadresse på formen <gruppenavn>@gruppe.<institusjon>.no og kanskje er det ønskelig at studenter som oppretter grupper får epostadresse på formen <gruppenavn>@gruppe.stud.<institusjon>.no, mens ansatte som oppretter grupper får epostadresse på formen <gruppenavn>@gruppe.<institusjon>.no

https://support.office.com/en-us/article/Multi-domain-support-for-Office-365-Groups-Admin-help-7cf5655d-e523-4bc3-a93b-3ccebf44a01a

Dynamisk gruppetilhørighet

AD attributter kan benyttes til å dynamisk tilordne brukere til Office 365 grupper:

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-groups-dynamic-membership-azure-portal

Mobile apper for grupper

Mobile apper beregnet for grupper kan hentes fra: http://groups.outlook.com/

Office 365 API

https://graph.microsoft.io/en-us/

Moduler

OneDrive for Business

Administrasjon:

https://admin.onedrive.com

Synkroniseringsklient gjør at du kan synkronisere lokalt lagrede filer til OneDrive for Business og omvendt.

https://onedrive.live.com/about/en-nz/download/

SharePoint

Delve

Ved ønske om å disable/enable Delve, så kan dette gjøres globalt for tenant`en ved å fra Administrator modulen i Office 365 velge Administrasjonssentre -> SharePoint -> Innstillinger -> Office Graph -> Ikke tillat tilgang til Office Graph / Tillat tilgang til Office Graph

Video

Ved ønske om å disable/enable Office 365 Video, så kan dette gjøres globalt for tenant`en ved å fra Administrator modulen i Office 365 velge Administrasjonssentre -> SharePoint -> Innstillinger -> Kontroller om videoer lagres og strømmes fra Azure Media Services -> Deaktiver strømming av video via Azure Media Services, og deaktiver videoportalen / Aktiver strømming av video via Azure Media Services, og aktiver videoportalen.

Tilgang til å opprette nye video-kanaler er standard tillatt for alle brukere i tenant`en. Normalt vill det være ønskelig å begrense dette til en gruppe eller utvalgte personer. Dette gjøres ved å åpne Video modulen -> «Portal Settings», for så å justere innholdet i «Kanaladministratorer». Sikkerhetsgrupper eller enkeltbrukere kan legges inn her.

Office 365 Video benytter SharePoint Online som lagringsområde. Hver kanal som blir laget får opprettet en ny SharePoint Online Site Collection under stien https://<tenant-navn>.sharepoint.com/portals/<kanal-navn>

Her er noen PowerShell moduler som kan benyttes til å sjekke og kontrollere Video lagring:

Notis: Stream vil erstatte Office 365 Video - https://blogs.office.com/2016/07/18/what-microsoft-stream-means-to-office-365/https://blogs.office.com/2016/07/18/what-microsoft-stream-means-to-office-365/

Skype for Business / UH-Skype

«UH Skype» fra UNINETT tilbyr Skype for Business som en skytjeneste og er tilgjengelig som produkt for alle UNINETT sine kunder. Tjenesten er basert på en «on-premises» versjon av Microsoft sin Skype for Business-plattform. Den redundante serverplattformen er sentralt driftet av tjenesten og den enkelte kunde forholder seg bare til egen AD og Exchange for håndtering av egne brukere. I tjenesten benyttes organisasjonens eget domene slik at man kan gjøre eventuell nødvendig federering mot andre organisasjoner. Tjenesten fungerer som hybrid-løsning i tilfeller hvor kunden samtidig ønsker å benytte tjenester fra Office 365.

For å kunne ta i bruk tjenesten «UH Skype», kreves også bruk av tjenesten «UH AD» for synkronisering av nødvendig brukerinformasjon med organisasjonens egen AD.

«UH Skype» kan leveres både uten eller med funksjonen «Enterprise Voice» for telefoni. Dersom det ønskes telefoni, leveres det gjennom tjenestene «Sanntid» og «Sanntid tale» slik at man kan benytte de telefonnummer man allerede besitter i organisasjonen. «Sanntid tale» er knyttet opp mot den til enhver tid aktuelle avtalepartneren på telefoni. Gjennom «Sanntid» kan man også få tilpassede hybridløsninger for gradevis migrasjon fra gammel til ny telefoniplattform og tilleggsløsninger for bl.a. telefonkonferanser, faks-håndtering (fax-to-mail) og spesielle viderekoblinger av nummer.

Gjennom «Sanntid» vil alle organisasjonens telefonnummer også bli registrert i ENUM. Det tilgjengeliggjør organisasjonen for direkte oppringing fra organisasjoner som støtter dette, uten å gå veien via en telefonoperatør.

Konferansenummer til bruk i «Skype for Business» vil være til et fritt valgt nummer fra organisasjonens egne nummerserier.

«UH Skype» er teknisk fleksibel med hensyn til behovet for støttesystem og 3djepart integrasjoner. Plattformen har full tilgang til UCMA APIet og et teknisk forum tilrettelegger vurderer fortløpende behov for integrasjon etter bl.a. innmeldinger fra kundene.

Tjenesten støtter alle sentralbordsystemer som er basert på telefoniruting, samt Trio og Competella med sine API-integrasjoner.

«UH Skype» er også tett integrert med tjenesten «Nasjonal Videobro» som bl.a. gir utvidet videomøtefunksjonalitet og sømløs oversettelse mellom formatene SfB, SIP, H323 og WebRTC.

Exchange Online

Gjenstår å skrive om

Stikkord:

  • Hybridløsning
  • Exchange Online Protection
  • Hvordan migrere mailbokser? Eksempel på verktøy som kan benyttes - https://www.bittitan.com/

Se kapittel 10 i UNINETT & Advania - Startpakke Office 365

Office 365 Security & Compliance Center

«Office 365 Security & Compliance Center» er en portal som kan benyttes av Office 365 Administratorer til å beskytte og kontrollere data i Office 365.

https://protection.office.com/#/homepage

Support/dokumentasjon:

https://support.office.com/en-us/article/Security-and-Compliance-in-Office-365-for-business-Admin-Help-7fe448f7-49bd-4d3e-919d-0a6d1cf675bb?ui=en-US&rs=en-US&ad=US

Kontroll på endringer

Microsoft videreutvikler Office 365 kontinuerlig og det vil derfor være behov for å følge med på de endringene Microsoft implementerer / planlegger å implementere i Office 365. Microsoft har en rekke kommunikasjonskanaler de bruker for å informere om endringer:

I tillegg til å følge med på disse kommunikasjonskanalene bør det gjøres et valg i forhold til hvilken «Release versjon» en skal ta i bruk. Det finnes to typer «Release versjoner» i Office 365:

  • First Release – Her kommer nye oppdateringer først.
  • Standard Release – Her kommer oppdateringer senere.

Innenfor en tenant er det mulig å velge ut brukere som skal ha «First Release Option», mens resten av brukerene skal ha «Standard Release». Eller en kan velge å sette dette globalt på tenant nivå.

Anbefaling vil være å benytte «Standard Release» i produksjons-tenanten. Videre bør en vurdere å opprette en demo/test-tenant der «First Release» er skrudd på enten globalt eller på enkelte brukere.

For implementering se:

https://support.office.com/en-us/article/Office-365-release-options-3b3adfa4-1777-4ff0-b606-fb8732101f47?ui=en-US&rs=en-US&ad=US

Begrensninger

Forskjellige moduler i Office 365 har tekniske begrensninger/grenseverdier som en bør være kjent med. Dette kan gå på begrensninger i forhold til for eksempel maksimum lagringsmengde og maksimum antall elementer som kan lagres/opprettes. Disse begrensningene kan også være forskjellig mellom forskjellige typer Office 365 lisenser. Kapittel 6 i Advania dokumentet lister opp et utvalg av grenseverdier:

http://startpakke.uhsky.no/docs/saas/office365/documents/Office_365-Arbeidsdokument_2_Design_og_anbefalinger_v1.4_(004).pdf

Slike grenseverdier endrer seg over tid og en bør derfor selv sjekke/verifisere de grenseverdiene en synes er viktig å ha et forhold til.

Skype for Business Online:

https://technet.microsoft.com/nb-no/library/skype-for-business-online-limits.aspx

Exchange Online:

https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx

SharePoint Online:

https://support.office.com/en-us/article/SharePoint-Online-software-boundaries-and-limits-8F34FF47-B749-408B-ABC0-B605E1F6D498?ui=en-US&rs=en-US&ad=US

Office 365 Video:

https://www.yammer.com/itpronetwork/#/Threads/show?threadId=696804199