Nu är Project Moca, också känt som Outlook Spaces tillgängligt att testa i en förhandsversion. Du kan höra mer om Project Moca i Office 365-podden S02E12 som snart publiceras. I det här inlägget förklarar jag vad du behöver göra för att slå på det i din egen tenant, i min beskrivning nedan slår du på det för hela organisationen.
Först måste du givetvis vara behörig att skapa mailboxpolicies och du måste ha PowerShell och ExchangeOnline v2 modulen. Anslut till Exchange Online.
Connect-ExchangeOnline
Sedan kan det vara smart att kolla om det redan finns en policy som slår på Project Moca i din tenant.
Get-OwaMailboxPolicy| fl name, *moca*
Det är också smart att kolla vilken policy som gäller för dig.
Det finns en standardpolicy som ofta (men inte alltid) omfattar alla användare, sannolikt är det den som visats ovan. Det är ofta den du skall koppla på Project Moca.
…jag skall inte nämna det, jag skall inte nämna det, jag skall inte.. COVID-19.
Ok, jag nämnde det.
Men det här inlägget skall egentligen handla om att arbeta hemifrån, ett ämne som är högaktuellt på grund av.. Ja, du vet. Nu är ju jag egenföretagare, och jag har mitt kontor hemma så även om jag arbetar från kaféer, bibliotek, och andra allmänna platser ibland så blir det ju så att de flesta dagarna sitter jag just hemma.
Men för dig som är anställd på ett företag så är det kanske en större utmaning att arbeta hemifrån. Även om du kanske mest jobbar som en så kallad knowledge worker.
För oss som inte pysslar med rutinuppgifter som kräver fysisk närvaro så skulle man kunna tänka att det är enklare att arbeta hemifrån i ett sådant här läge, men i verkligheten har vi i åratal låst den möjligheten med möten, möten och åter möten.
Det finns naturligtvis ingenting positivt med ett stort virusutbrott. Jag vill bara ha sagt det innan jag fortsätter med mitt resonemang.
Experimentvilja
I sådana här tider är vi människor ofta mer experimentvilliga. Istället för att fokusera på problemen, dvs vad man inte kan göra ifall människor sitter hemma istället för att vara på arbetsplatsen, så kan man välja att fokusera på vad man kan göra när människor sitter hemma under arbetstid.
En av fällorna tror jag är att man automatiskt tänker att vi skall arbeta på samma sätt. Samma processer. Samma möten fast elektroniskt. Jo, det är naturligtvis ofta så att man har processer som är inarbetade och det kan vara svårt att hoppa över steg i den processen utan att det blir pannkaka av en leverabel. Men det måste inte vara så.
Photo by Arlington Research on Unsplash
Jag tror att vi kan göra våra organisationer och processer mindre sårbara genom att tänka om. Det finns kanske flera bra svenska uttryck men jag kan inte komma på något enda nu för att ersätta engelskans re-imagine. En kris kan ibland vara en katalysator för nya tankar. Nya sätt att arbeta. Tvånget att ta ett steg i en ny riktning.
Metoder
Det finns ett ramverk för beslutsfattande som heter Cynefin som bringar reda i vårt sätt att agera i sådana här situationer. Cynefin talar om fyra olika lägen man kan befinna sig i och ger en fingervisning om hur vi skall agera. Det första läget är det Uppenbara. Vi känner till alla parametrar och hur de fungerar. ”Det kända kända” Det finns en best practice. Angrepssättet blir här ”Observera, kategorisera, åtgärda.” Lampan lyser inte. Vi testar om andra lampor fungerar för att utröna om det är en trasig lampa eller problem med elförsörjningen. Därefter kan vi byta säkringen eller lampan eller plugga i kontakten. Nästa läge är det komplicerade. Detta är det kända okända. Det finns flera sätt att hantera problemen, flera orsak/verkan-förhållanden, och vi kan behöva experthjälp för att välja det bästa. Här finns ingen Best Practice, bara Good Practice. Angrepssättet blir ”Observera, analysera, åtgärda”. Sedan kommer det Komplexa läget. Det okända okända. Här finns inga rätta svar, inga experter som kan lösa det åt oss. “Prova, observera, åtgärda” är stegen här. Testa försiktigt, blev det bättre eller sämre? Det fjärde läget är Kaos. Här skall vi bara ”Agera, observera, åtgärda”. Vi prövar något, vad som helst i syfte att stabilisera situationen. Rätt eller fel, vi måste göra nånting.
Det finns faktiskt ett femte läge, och det är förvirring och handlingsförlamning. Och det är ofta från den här punkten vi startar vårt beslutsfattande. Vi måste klura i vilken av de fyra boxarna vi skall lägga det som uppkommit.
Tänk om vi alla tvingas jobba en månad hemifrån. Vilken box är det? Hur skall vi göra för att hålla affärerna igång? Hur kan vi ge ett värde för våra kunder, och våra arbetskamrater?
Nu har världsturnen av Ignite kommit till Köpenhamn och jag är en av de lyckliga som har möjlighet att besöka eventet. Till Stockholm kommer turnen först 5-6 maj, det är ju ett tag tills dess.
Mycket folk är det såklart vilket en del tycker är avskräckande i Corona-virusets tidevarv. Har redan fått en fråga från en kund ifall alla här går runt med munskydd, men så är det inte.
Vid incheckningsköerna var det såklart långa köer men det gick väldigt smärtfritt att registera sig och få sin badge.
Jag har inte varit på ett sådant här event, men det är väsentligt mindre än till exempel European SharePoint Conference (ESPC).
Jag uppdaterar den här posten när jag hinner under dagen.
Intelligent Intranet Accelerator Workshop
Imorgon eftermiddag har jag tänkt att gå på workshopen där man bygger intranet hands on, men jag funderar på hur mycket jag kommer att lära mig. Man lär sig alltid något så jag är inte orolig, snarare förväntansfull. Redan har jag hittat några saker:
i Mars kommer förmågan att schemalägga publicering av sidor och nyheter
Utvecklingstakten har inte minskat. Det är lätt att tro det nu när man pratar så mycket om Project Cortex, att man fokuserar på det.
Nu skall jag sitta på en dragning om Common Data Service
Och det behövs, är lite förvirrad där. Återkommer…
(Shoutout till Bryan, kul att se dig!)
Sedan en tid tillbaka har vi haft möjlighet att deklarera ett dokumentbibliotek som ett ”Organizational Assets Library”. Meningen med det är att vi skall kunna lägga godkända bilder, loggor och liknande i ett gemensamt dokumentbibliotek. På det viset blir det lättare t ex för artikelförfattare att använda rätt bilder i sina artiklar. Man kan ha flera sådana bibliotek som du kan se i bilden överst, det enda som krävs är att alla biblioteken ligger på samma sajt, så skapa en specifik sajt för det här och lägg allt där. Glöm inte att låta alla anställda få behörighet till sajten. Man behöver använda PowerShell för att fixa ett sådant här bibliotek, men det är inte supersvårt. Allt du behöver kan du läsa på dokumentationen av funktionen i Microsoft Docs.
Du kan göra detsamma för dokumentmallar
Det är det här som är det nya. Ett av bekymren vi har i en organisation är att se till att alla har tillgång till och använder organisationens godkända dokumentmallar.
Organizational Assets libraries stöder nu en bibliotekstyp som kan göra organisationens Office-mallar tillgängliga. När du deklarerar ett dokumentbibliotek som ett Organizational Assets Library så anger du vilken typ av bibliotek du vill sätta upp med parametern -OrgAssetType och då kan du sedan välja OfficeTemplateLibrary om du vill göra officemallarna tillgängliga (istället för ett ImageDocumentLibrary som du väljer när du skapar bildbibliotek).
Den här möjligheten är så ny att den fortfarande är odokumenterad hos Microsoft men den fungerar utmärkt.
Det enda jag saknar nu är att även bildbiblioteken görs tillgängliga för Office, så att jag får tillgång till loggor och bilder när jag skapar dokument i tex Word eller PowerPoint.
Jag har många kunder som använder multifaktorautentisering och det på goda grunder. Sannolikheten att ett konto blir komprometterat minskar enormt bara genom att vi kräver fler faktorer för att godkänna en inloggning. Men hur gör man? Vilka är riskerna? Hur skall man resonera?
Resonemangen
Det finns ett antal frågor som man kanske skall försöka besvara innan man startar med sin implementation.
MFA för alla eller bara för en del
MFA är inte bara en säkerhetsfördel, det är också en risk. Om vi tänker oss den gyllene triangeln av säkerhet: Konfidentialitet, Integritet och Tillgänglighet. Just den sista punkten, tillgänglighet, tillhör en av riskerna med MFA. Vi har bara under 2019 hittils haft tre incidenter där MFA i Azure AD (som används för Office 365) legat nere och därmed gjort Office 365 otillgängligt.
Om vi nu kräver MFA för alla användare så kan ingen, varken administratör eller användare komma åt vare sig mail, Teams, SharePoint eller någon annan tjänst som Office 365 innehåller. Enbart den som redan är inloggad när MFA-haveriet sker kan fortsätta arbeta.
Om vi kräver MFA för alla högriskanvändare, dvs alla användare som har åtkomst till extra känslig information, så är enbart de påverkade av haveriet.
Om vi kräver MFA för alla administratörer, vilket Microsoft rekommenderar som en basnivå på säkerhet, så kan vi inte administrera och vi kan heller inte reagera och hantera eventuella angrepp som sker medan MFA är otillgängligt.
Att slå på MFA
Att slå på MFA är ganska enkelt. Det kräver två moment.
att jag "enablat" eller slagit på MFA-stödet för användaren
att användaren registrerat sig för MFA
När användaren registrerar sig för MFA så väljer användaren på vilket sätt denne vill verifiera sin identitet. Det kan vara:
Ett telefonsamtal som man svarar på och trycker fyrkant för att bekräfta inloggningen
Ett SMS med ett numeriskt engångslösenord som jag knappar in i en extra inloggningsdialogruta
App-verifiering, där jag har en autenticeringsapp på min mobiltelefon i vilken jag bekräftar att det verkligen är jag som loggar in.
När olyckan är framme
Så vad händer då om MFA är otillgängligt och jag inte kan komma åt tjänsterna? Ja, om vi bara har en enda administratör som antingen redan är inloggad eller om jag har ett i nödfall krossa glaset -adminkonto så kan jag naturligtvis "disabla" eller stänga av MFA för vissa eller alla anvöndare, men det innebär att registreringsinformationen försvinner och när jag slår på MFA igen måste användaren registrera sig på nytt.
MFA alltid eller bara ibland
Multifaktorautensiering behöver ju inte vara i effekt alltid. Om vi skaffar licens för våra användare till tjänsten Azure AD P1 så kan vi ha villkorsstyrd MFA.
Vilkorsstyrd MFA är ganska praktiskt eftersom vi kan sätta regler för när vi skall kräva en extra faktor. Till exempel kan vi kräva en extra faktor så fort vi befinner oss utanför betrodda nätverk, som t ex när jag är på besök hos kund, eller sitter på ett kafé. Jag kan också kräva en extra faktor när jag accessar vissa tjänster.
Om jag har Intune-licens och min enhet är registrerad som en betrodd enhet så kan jag slippa bekräfta min identitet.
MFA eller inte MFA
Jag tillhör dem som tycker att MFA verkligen tillför extra säkerhet men också en extra problemdomän, och just problemdomänen är något jag verkligen betonar att du behöver ha tänkt igenom först innan du slår på MFA.
Nu har Microsoft pensionerat de personliga bloggarna i Delve, och på sikt kommer existerande innehåll att tas bort. För de allra flesta är det inte en stor fråga men för dig som faktiskt använt bloggarna är det knöligare. Nu måste du ju ersätta dem på något sätt med en ny funktion.
I klassisk SharePoint finns det stöd för en bloggsajt, men det finns det ju inte i Modern SharePoint. Dessvärre. Här finns bara två sajtmallar som är tillgängliga från grunden och det är en gruppkopplad Teamsite och en Modern Communications site. Men Microsoft har ändå en rekommendation, och det är att man använder nyhetsfunktionen i SharePoint istället. Nyheter är en viktig funktion i moderna sajter och finns i bägge sajtmallarna. Faktum är att man kan säga att Nyheter är en modern bloggningsfunktion. I grunden så är en nyhet ett blogginlägg med ett annat namn. Om man vill anpassa funktionen så kan man lägga till ytterligare metadata om man vill. Mer om det i sektionen Skapa sajtkolumner för att hålla extra information nedan.
Nyheter och SharePointsidor
Grunden för moderna sharepointsajter är bland annat det vi kallar för sharepointsidor eller "site pages". de är lätta att skapa, att underhålla och kan konsumeras mycket enklare än t ex ett dokument. De är mycket lätta att läsa i SharePoint-appen på din mobil, de går enkelt att lyfta fram för en specifik publik. Så många gånger skall vi hellre bryta ner ett komplicerat ämne på flera sharepointsidor än att skapa ett långt dokument. En variant på sharepointsidan är nyhetssidan.
Den som både skapat en sida och en nyhet i SharePoint kan ganska snart se likheterna mellan moderna sharepointsidor och en nyhetssida. Och det är inte fel att säga att en "nyhetssida" är en variant på en modern SharePoint-sida. Det som är den egentliga skillnaden är faktiskt bara några egenskaper. Det som skiljer i övrigt är bara hur nyhetssidor hanteras av SharePoint. Nyheter kan t ex med enkelhet syndikeras till andra sajter i samma Office 365-instans.
> Tekniskt sett är det två egenskaper som skiljer de olika sidtyperna. Egenskapen PromotedState som är 0 för en vanlig sida och 2.00000000000000 för en nyhet. Den andra egenskapen är FirstPublishedDate som har en giltig tidsstämpel på en nyhetssida medan en vanlig sida saknar värde här.
Vanlig sida: "PromotedState":0.0,"FirstPublishedDate":null,
Så egentligen är det väldigt lite skillnad på dem. Så fort "PromotedState" sätts till 2.0 så behandlas sidan som en nyhetssida snarare än en annan sida. Däremot ser datumet knasigt ut ifall "FirstPublishedDate" inte har ett giltigt värde.
Tips och Trix med SharePoint-sidor
Som alla sidor i SharePoint kan vi naturligtvis hänga på ytterligare metadata för att sortera lite bland nyheterna. Det gör vi genom att skapa sajtkolumner och lägga till dessa i sidbiblioteket. Men först måste vi kanske klura ut vilka kategorier vi behöver: Kanske produkter, avdelningar eller geografiska beteckningar är lämpliga i din organisation? På samma sätt kan vi också skapa en kolumn med "taggar" om vi behöver sådan funktionalitet.
Flera olika bloggar/ämnen
Så om vi vill kunna kategorisera och sortera upp inläggen i olika ämnen så behöver vi förse våra nyhetssidor med fler egenskaper. Det gör vi bäst genom att skapa en grupp med bloggegenskaper. och koppla dem till sidbilioteket.
Skapa sajtkolumner för att hålla extra information, så som kategori
Logga in i SharePoint som ägare av sajten
klicka på kugghjulet i högra hörnet
Öppna Site Settings
Under Web Designer Galleries så klickar du på Site Columns
Klicka på Create för att skapa Bloggkategorierna/Ämnena
Ge kolumnen ett namn, t ex Blog Category
Choice är ofta ett bra val som informationstyp, Det är lätt att det blir fel när folk skall författa artiklar om de måste skriva in kategorin manuellt
Skapa en ny grupp att lägga denna kolumn i, jag rekommenderar att du lägger ett understreck som första tecken i namnet på gruppen. T ex _BlogColumns
Under Additional column settings så lägger du in din lista på bloggkategorier/ämnen under Type each choice on a separate line. Du kan också välja vilket alternativ som skall vara standard under rubriken Default value.
klicka på OK längst ner till höger för att spara.
Klicka på Create igen ifall du vill skapa en kolumn för taggar. Samma val, förutom det jag räknar upp nedan:
Använd den nu redan existerande gruppen du skapade nyss, den bör ligga överst i listan.
Kryssa i Yes under Allow ‘Fill-in’ choices
Skriva en Nyhet/Blogginlägg
För att nyttja den funktionalitet vi nu har lagt till skall vi bara komma ihåg att öppna sidegenskaperna och ange värden för kategori och taggar när vi skriver en nyhet/blogginlägg.
Publicering
Det finns två webparts vi kan använda för att publicera våra nyheter. Den första är förstås webparten News, men man kan också använda webparten Highlighted Content. För just bloggändamål föredrar jag faktiskt News. News har möjligheter att filtrera vad som skall visas. Så om jag bara vill visa inlägg i kategorin "Konsultliv" eller "Teknik" så kan jag enkelt åstadkomma detta genom att specificera vilka kategorier som skall visas.
Nyhetssidor är ett fantastiskt sätt att sprida information i din organisation, och är mycket mer användbart än du kanske tänker dig. Läs mer om nyheter på Tracy Van Der Schyffs blogginlägg om News
Autosave är väldigt bra, det är en av funktionerna som gör att det går bra att kollaborativt ta fram dokument, där flera är inne och redigerar eller författar samtidigt. Vi slipper också problem med dataförluster ifall vi är slarviga när vi avslutar redigeringen. Och visst kan den också vålla problem också, vi kan råka göra fel när vi skall korta ner en presentation t ex. Där är det ju tänkt att vi först skall spara en kopia och redigera i kopian, och inte först ta bort material och sedan spara en kopia. Autosave gör ju att även originalet blir förkortat i det läget. Lösningen om det händer är att återställa föregående version av originalet genom att titta på dokumentets versionshistorik i OneDrive/SharePoint.
Avsiktliga signaler i Graph
Microsoft Graph fångar olika händelser (de kallas Signaler i Graph) så som när du läser ett dokument och när du ändrar ett dokument. Dina läshändelser är privata, dvs det är bara du själv som kan se att du kikat på ett dokument, medans att du författat eller redigerat ett dokument blir en publik signal. Det är så t ex Delve vet att den skall lyfta fram ett viss dokument i vyn för dig och dina medarbetare. Om du och jag bägge arbetar med "Projekt Beltalowda" och jag skriver ett dokument med hör till projektet så kommer det att bli synligt i Delve när du går in där. Graph har flaggat det som relevant för dig eftersom du och jag jobbar i projektet. Precis så är det tänkt att Delve skall fungera. Dokumentet hittar dig, och inte bara tvärtom.
Oavsiktliga signaler i Graph
När du läser ett dokument som handlar om tjänstledighet, föräldraledighet, sexuella trakasserier eller något annat ämne som kan vara känsligt, så blir signalen privat och ingen annan kan se att du läst dokumentet. Men ifall du har skrivrättighet i dokumentet så kan det ställa till det ordentligt. Det räcker med att du råker trycka in ett mellanslag eller vad som helst, så kommer autosave att spara det direkt. Signalen blir nu publik och du kan inte längre dölja att du varit inne i dokumentet. Även om du återställer dokumentet i en tidigare version. Det är också en publik signal och kopplingen mellan dig och dokumentet blir nu ännu starkare i Graph. Därför är det oerhört viktigt att användare inte har skrivrättighet i dokument som kan vara känsliga. Formulär för anmälningar eller liknande bör göras i Forms eller annan liknande teknik och inte ligga som skrivbara dokument i dokumentbiblioteket.
Mats Warnolf AB 