 |
| Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | Visa i webbläsaren | /_layouts/images/ichtmxls.gif | /_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | Visa i webbläsaren | /_layouts/images/ichtmxls.gif | /_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Ögonblicksbild i Excel | /_layouts/images/ewr134.gif | /_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Ögonblicksbild i Excel | /_layouts/images/ewr134.gif | /_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
|
 |
|
|
|
|
|
|
|
|
2011-10-28För alla skolor och kommuner som har ett AD är federering den rekommenderade metoden för identiteshantering. Endast för test bör man skapa och underhålla konton manuellt. Till skillnad från manuell hantering kräver federering en hel del planering och även tekniskt kunnande.
För att sätta upp federering behövs (minst) två delar:
- En trust mellan Office 365 och det egna AD
- En applikation, DirSync, som replikerar konton och deras attribut från AD till Office 365
En trust sätts upp för att konton i det egna AD ska kunna kopplas mot ett motsvarande konto i Office 365. Det kommer alltså att vara två separata konton, men de kopplas ihop via ett attribut som man bestämmer i trusten, oftast e-postadress. Denna koppling kräver ADFS 2.0.
När trusten är på plats sätter man upp DirSync, som är en applikation som läser konton i det egna AD och skapar upp motsvarande i Office 365. Notera att det i dagsläget inte är möjligt att använda ILM/FIM eller Powershell för att skapa dessa konton. Man måste alltså använda DirSync. Klicka på länkarna för mer information om DirSync eller för att ladda ner DirSync.
Det är viktigt att planera införandet av Office 365 så att implementeringen blir så smidig som möjligt. Om man har Live@edu idag, eller planerar att skaffa det i väntan på Office 365 for education bör man ha federeringen i åtanke redan nu. Det gäller både hur man sätter upp domänen och hur man skapar konton. 2011-10-21
Om man försöker inaktivera en mall kan man få ett fel som säger att det inte går att aktivera den för att det finns en webbplats som antingen är borttagen eller felaktig.
I de fall jag har stött på detta beror felet på att det finns en länk mellan webbplatser och den mall som de skapats med. Om man tar bort en webbplats hamnar den i webbplatssamlingens papperskorg. Där ligger den i 30 dagar (om man inte ändrat det) innan den försvinner helt. Under tiden finns referenser både till webbplatsen och till webbplatsens innehåll kvar i databasen, vilket gör att mallen inte går att inaktivera. Om man går till webbplatssamlingens papperskorg ( Webbplatsåtgärder - Webbplatsinställningar - Administration av webbplatssamling - Papperskorg) ( _layouts/AdminRecycleBin.aspx) ser man bara listobjekt, inte webbplatser. Därför räcker det inte att tömma papperskorgen här, men man kan göra det med Powershell:
$site = Get-SPSite http://sitename$site.RecycleBin.DeleteAll() $site.Dispose()
Detta kan lösa problemet. 2011-10-14Office 365 släpptes i juni 2011 och har redan blivit en stor succé. Som efterföljare till Microsoft driftade företagstjänst - BPOS - innehåller den tjänster som Lync, Exchange, SharePoint och Office. Enligt Microsofts vision är det där "Office och molnet möts". Live@edu kommer att ersättas av Office 365 i en något modifierad version, "Office 365 for education". Exakt vad denna modifiering innebär är inte helt klart, men den kommer bland annat innehålla vissa skolanpassade mallar och såklart en anpassad prissättning.
Tjänsterna innebär:
- Lync - Chattklient som även innehåller ljud och video. Läraren kan sända en presentation Live eller spela in den så att elever kan titta på den senare. Eleverna känner igen detta program eftersom det påminner om Messenger och man kan även lägga till Livekonton som kontakter.
- Exchange - E-post med adressböcker, kalendrar, filer och mappar.
- SharePoint - Virtuella rum på webben där lärare och elever kan samarbeta.
- Office - Officeprogrammen på webben. Office 365 innebär även att användarna kan ladda ner och installera det på sina datorer.
En skola kommer riktigt långt på detta och det blir en mycket kostnadseffektiv tjänst. Med SharePoint Online får man samarbetsrum för elever och lärare, men för att tjänsten ska bli effektiv måste man se till att klass-, kurs- och ämnesrummens deltagare uppdateras automatiskt. Detta görs till exempel med en koppling till skolan/kommunens elevregister. Man kommer också att behöva vissa specialanpassade funktioner, t.ex. inlämningsmapp, portfolio och loggbok, men i övrigt är tjänsten mycket bra för det pedagogiska arbetet.
För de administrativa funktionerna finns få verktyg. Där behövs tillägg från tredje part och som tur är finns det ett bra ramverk för att lägga till "sandboxed solutions". Det gäller funktioner som schemavisning, närvarohantering, omdömen, iup, studieplaner och betygssättning. Använder man Office 365 som plattform bör man skaffa funktioner som är komplatibla med detta för att användarna ska få en så bra upplevelse som möjligt ("best user experience").
2011-10-06
Denna artikel gäller felmeddelandet "Klienten har inte stöd för att öppna den här listan med Utforskaren", som kan dyka upp när man försöker öppna ett dokumentbibliotek i utforskarläge. I detta specifika fall handlar det om en miljö med SharePoint 2010 och autentisering sker med ADFS v2. Klienten körde vid testning Windows 7 x32.
När man öppnar ett dokumentbibliotek i utforskarläge i SharePoint görs det via WebDAV. WebDAV är ett sätt att kommunicera för att att mappa dokument och filer via webbservrar (ungefär som ftp) och körs över port 80, så det ska inte vara något problem med brandväggar. Att felmeddelandet säger "klienten" är förvillande, för problemet kan mycket väl ligga på servern.
För att utforskarläge ska fungera måste man aktivera tjänsten "WebClient". När man installerar Windows Server 2008 R2 med SharePoint 2010 är inte det aktiverat per default. För att göra det går man in i Server Manager - Features och aktiverar funktionen Desktop Experience.
Detta måste göras på alla WFE och efter att man gjort detta måste servern startas om. Efter omstart går man till Server Manager - Services och startar tjänsten WebClient. Se till att den är satt att startas automatiskt.
Lägger man sedan siten i trusted zone eller local intranet ska användaren slippa extra inloggning vid öppnande av utforskarläge. För autentisering med ADFS är detta ett krav. Det finns ingen koppling mellan utforskarläge och att koppla till Outlook eller via i databladsvy, eftersom det använder webservices. 2011-10-03Microsoft annonserade idag att det under hösten kommer en uppdatering till Office 365 som tillåter kommunikation med Azure via Business Connectivity Services (BCS). Detta tillkännagavs under SharePoint Conference 2011 i Anaheim av Jared Spataro, Senior Director of SharePoint Product Management. Fördelen med detta är att man snabbt kan skapa kopplingar till egna databaser och visa upp information via externa innehållstyper (external content types) direkt i SharePoint Online.
När man läser befintliga konton i AD och skapar konton för dem i Live@edu finns det en önskan att ha samma lösenord i AD och i Live@edu. För nya konton kan man eventuellt sätta samma lösenord på AD-konton och Live@edu-kontot vid skapandet, men även där finns en risk att användaren snart kommer att ha olika lösenord i de båda systemen. Lösningen är att ha en Single-Sign-On (SSO) mellan systemen. Microsoft utlovade federering via AD FS 2.0 under "första kvartalet 2011", men då det inte skulle gå att överföra detta till Office 365 (som släpps för skolor under 2012) har man valt att inte stödja det alls i Live@edu, utan endast i Office 365.
SSO via certfikat Den enda lösning som finns nu är att använda certifikat för att skapa SSO. Detta certifikat finns dels på domänen och dels i ett lokalt "certificate store" och kan skickas med vid autentisering mot domänen. Via kod anropas domänen med ett användarnamn och certifikatet. Från domänen får man ett Short Lived Token (SLT) som sedan används vid anrop till tjänster i Live. Man behöver alltså inte känna till användarens lösenord. Figuren nedan visar denna process mer i detalj.

Det finns idag webbdelar och funktionalitet för SharePoint att hantera detta. Har man inte SharePoint kan man sätta upp en IIS-applikation som känner av inloggad användare, hämtar namnet på upp användarens Live-Id, via certifikat skapar en SLT mot Live@edu, loggar in användaren där och skickar sedan vidare webbläsaren dit. För användaren ser det ut som att man anropar epost.skolan.se, men i själva verket är det bara en applikation som loggar in och skickar vidare användaren till www.outlook.com. Om man sätter autentiseringsmetod till Windows Authentication och NTLM ska användaren inte behöva någon extra inloggning om datorn är domänansluten. Notera att denna lösning bara fungerar för webbapplikationerna Outlook Live och Livetjänsterna. Om man ska använda Messengerklienten eller spara i sin Skydrive från Office måste användaren känna till sitt användarnamn och lösenord i Live.
Lösenordssynkronisering För lösenordssynkronisering kan man använda några olika metoder. Till exempel kan man i ovanstående webbapplikation lägga in en funktion för att byta lösenord. Denna funktion anropar en webbservice som byter och sätter samma lösenord i båda (alla) system. Detta fungerar även från SharePoint. Integrationsmotorn FIM (tidgare ILM) har också webbfunktionalitet för detta. Det går också att installera ett lösenordsfilter som fångar upp om användare t.ex. trycker Ctrl+Alt+Delete på sin dator för att byta lösenord i AD. Detta filter kan sedan anropa ovan nämnda webbservice för att även byta lösenord i Live@edu. Notera att detta filter måste installeras på domänkontrollanten och kräver en omstart av servern. Kombinerar man dessa metoder kan man förhoppningsvis uppnå önskad funktionalitet.
Om detta verkar krångligt så är ovan nämnda AD FS 2.0 den utlovade lösningen på alla problem. Se bara till att förbereda din domän för detta redan nu. 2011-09-13
Från och med 1 oktober ändrar Microsoft den URL-adress som används för att verifiera ett Windows Live ID. Detta påverkas endast implementationer som använder certifikat för SSO mot Live@edu, t.ex. via en webbapplikation eller via SharePoint. Det är endast adressen som ändras, ingenting i förfarandet.
Tidigare url
Den nya adressen kan användas redan nu och om den inte gör det före den 1 oktober kommer användarna inte kunna logga in. För LearnPoint-kunder är ändringen genomförd i LearnPoint 11.1.
2011-05-18
Idag har ViaEcole AB och SCAS AB slagit samman sina verksamheter i bolaget ViaEcole AB. Tillsammans kommer vi kunna svara på skolors och utbildningsverksamheters behov idag och i framtiden med fler och rikare produkter och lösningar.
ViaEcole har fram till idag haft sin kärnverksamhet kring lärportalen LearnPoint och integrationer mot många olika skolsystem, däribland Microsoft Live@edu/Office 365 for Education som vi i dagsläget skapat mer än 500.000 konton i. ViaEcole är guldpartner till Microsoft och en av dess absolut främsta partners inom skola och utbildning.
SCAS har fram till idag haft sin kärnverksamhet kring det elevadministrativa systemet SCAS - School Administration System, vilket har utvecklats i nära samarbete med flera olika skolor och utbildningsverksamheter. Även SCAS är sedan tidigare en mycket väl etablerad partner till Microsoft inom skola och utbildning och har också genomfört ett stort antal projekt kring Microsoft Live@edu.
ViaEcole kommer med andra ord verkligen bli en spelare att räkna med framöver med spetskompetens inom skola och utbildning samt Microsofts teknologier. VD i det gemensamma bolaget blir Martin Johansson. 2011-04-18I en tidigare artikel har jag kort beskrivit olika metoder att skapa konton i Live@edu. Det viktigaste poängen är att man alltid ska sätta upp en automatisk koppling redan från början och se till att man har en stabil nyckel mellan Live@edu och sitt källsystem. I denna artikel kommer jag att gå igenom de tre vanligast implementeringarna av automatiskt kontoskapande.
Microsofts agent för ILM, OLSync
Microsoft levererar en agent för ILM, OLSync. Det är den enda lösningen som är fullt supportad från Microsoft och som löpande underhålls. OLSync måste installeras på en ren ILM FP1, vilket innebär att inga andra agenter får vara installerade innan. Egentligen lägger OLSync till två agenter, en som pratar med AD och en som pratar med Live@edu, så i konfigurationen mappar man inte metakatalogens attribut, utan AD:s attribut mot attributen i Live@edu. Har man ingen metakatalog kan OLSync vara smidigt att sätta upp och det är fullt möjligt att sätta upp en separat ILM endast för Live@edu. Om man redan har en metakatalog måste man alltså rensa ILM för att installera OLSync först och lägga på övriga agenter sedan, eller modifiera agenten att fungera som en "vanlig" agent, alltså direkt mappning från metaversen. Det man får tänka på då är att installationsprocessen inte är supportad av Microsoft längre. Marks kommun är ett exempel på den senare lösningen.
Specialanpassad agent för metakatalog
Förutom att OLSync innebär en del anpassningar vid installation innehåller även agenten en del begränsningar i vad man kan göra med Live@edu. Därför finns det en några organisationer som byggt egna agenter. Eftersom alla lösningar på något sätt använder Powershell i slutändan, kan man sätta ihop en egen agent som gör samma sak, fast med de modifieringar man önskar. Man bör dock vara medveten om att detta inte är en supportad lösning från Microsoft och att det kan bli en dyr lösning då Microsoft löpande uppdaterar sitt API. Det är också svårt att kopiera OLSync, då den agenten använder metoder som inte är dokumenterade. Västerås kommun är ett exempel på en egen utvecklad agent till ILM. Om man använder Novells metakatalog, IDM, måste man använda denna (eller nästa metod).
VIM, egen lösning supportad från tredjepartsföretag
En tredje lösning är att sätta upp en egen lösning med anpassade metoder för att skapa och underhålla konton. Ett exempel på en sådan lösning är VIM där ett tredjepartsföretag kan garantera att koden fungerar och uppdateras i takt med Live@edu. Denna lösning använder man oftast om man inte har någon metakatalog, eller om man snabbt vill komma igång med en pilot. Den är oftast billigare och snabbare än agenter till en metakatalog. Exempel på organisationer som kör denna lösning är Lunds kommun (Procapita till Live@edu) och Karlskrona kommun (AD till Live@edu).
Det finns som visat flera typer av lösningar och det går även att kombinera dessa beroende på vilken funktionalitet man vill uppnå. Vilken som är den bästa lösning är svårt att säga generellt. Man måste utgå från de egna förutsättningarna. Oftast vill man bara ha en motor som sköter alla integrationer (metakatalogen) och det är också den snyggaste lösningen. Dock kan det bli en ganska dyr lösning och svår att underhålla, då Live@edu befinner sig i ständig förändring. Därför har den vanligaste implementationen varit den tredje, VIM, där den oftast använts för att replikera det interna AD till AD i Live@edu. Fördelarna med VIM är att den löpande uppdateras i och med förändringar från Microsofts sida och med förändrade behov från organisationerna.
Oavsett vilken modell man väljer bör man se till att den är förberedd för att hantera federering mellan det egna AD och Live@edu.
2011-04-03
Som administratör av Live@edu kan man använda Powershell för att hantera konton. Vill man göra något med mailboxar, t.ex. läsa ut e-postmeddelanden eller skriva in kontakter i den personliga adressboken är det Exchange Web Services som gäller och man kan mycket väl använda EWS Managed API för detta.
För att läsa ut e-postmeddelanden från en användares mailbox kan man göra på följande sätt:
ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010); service.Credentials = new NetworkCredential("ewsservice@live.viaecole.se", "P@ssword"); service.AutodiscoverUrl("testaccount@live.viaecole.se", delegate(string url) { return true; }); service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, "testaccount@live.viaecole.se"); service.TraceFlags = TraceFlags.All; Folder folder = Folder.Bind(service, WellKnownFolderName.Inbox); Console.WriteLine("Du har " + folder.UnreadCount + " olästa meddelanden");
Ett problem är att anropet för AutodiscoverUrl kan ta upp till 30 sekunder att genomföra, vilket gör prestandan oacceptabel. Denna url är dock samma inom domänen, vilket gör att man kan ta reda på den med ett 30-sekundersanrop och sedan cacha det och återanvända sitt service-objekt, t.ex.:
ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010); service.Credentials = new NetworkCredential("ewsservice@live.viaecole.se", "P@ssword"); service.AutodiscoverUrl("testaccount@live.viaecole.se", delegate(string url) { return true; });
foreach(string url in urls) { service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, url); service.TraceFlags = TraceFlags.All; Folder folder = Folder.Bind(service, WellKnownFolderName.Inbox); Console.WriteLine("Du har " + folder.UnreadCount + " olästa meddelanden"); }
Detta ger en mycket stor skillnad i prestanda när man arbetar med många konton. Notera att servicekontot ewsservice@live.viaecole.se måste ha behörigheter enligt tidigare blogginlägg.
| Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Redigera i webbläsaren | /_layouts/images/icxddoc.gif | /_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | Visa i webbläsaren | /_layouts/images/ichtmxls.gif | /_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | Visa i webbläsaren | /_layouts/images/ichtmxls.gif | /_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Ögonblicksbild i Excel | /_layouts/images/ewr134.gif | /_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Ögonblicksbild i Excel | /_layouts/images/ewr134.gif | /_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
|
|
|
|
|
|