Wortell, Microsoft en meer...

Office 365: Welke voorbereidingen kunt u treffen voor een migratie?

Wortell is in 2010 door Microsoft verkozen als beste Online Services Partner wereldwijd. Hierdoor hebben wij de mogelijkheden gekregen vroegtijdig met Office 365 te experimenteren in een Beta programma. In dit artikel zijn de ervaringen hieruit opgenomen. Daarnaast gaan wij in op de vereisten van Office 365 en de voorbereidingen die u in uw organisatie kunt treffen om Office 365 direct na beschikbaarheid in te kunnen zetten. Deze post is onderdeel van een serie. Wil je weten wanneer ik een nieuw scenario post? Volg me dan even op linkedin of twitter.

Microsoft is traditioneel een partij die zich primair richt op lokaal geïnstalleerde software. Office 365 is echter een clouddienst of Software as a Service oplossing. Gebruikers hebben de mogelijkheid om gebruik te maken van de service via een browser. Naast het via een browser kunnen consumeren van de Office 365 cloud diensten, gaat Microsoft echter een stap verder. Ze integreert de oplossing in de cloud met lokaal geïnstalleerde software om zo gebruikers het beste van beide werelden te bieden.

Minimale Systeemvereisten

Om gebruik te kunnen maken van Office 365 dient een gebruiker minimaal te beschikken over een browser. Hoewel Office 365 via bijna iedere browser te gebruiken is, ondersteund Microsoft officieel alleen Safari 4.x, Firefox 3.x en Internet Explorer 7 (of hoger). De inmiddels meer dan 10 jaar oude Internet Explorer 6 wordt niet meer ondersteund door Office 365. Hoewel Microsoft officieel Chrome niet ondersteund, is het wel mogelijk met deze browser de Microsoft online services te gebruiken.

Voor optimaal gebruik is naast de webbrowser echter ook een koppeling nodig met een lokale computer. Hiervoor dient rekening gehouden te worden met meer systeemvereisten. Zo dient de minimale versie van het besturingssysteem Windows XP SP3 te zijn. Natuurlijk worden ook Windows Vista (SP2) en Windows 7 ondersteund. Naast de Windows versies ondersteunt Microsoft tevens Mac OS X 10.5 (Leopard) en Mac OS X 10.6 (Snow Leopard).

Op het besturingssysteem dient vervolgens de Office 365 Service Connector geïnstalleerd te worden. De Office 365 Service Connector zorgt ervoor dat een lokaal systeem voorbereidt wordt op integratie met de online diensten. De lokaal geïnstalleerde Office applicaties worden aangepast zodat deze naadloos met Office 365 kunnen werken en wordt Windows Update verteld dat in het vervolg update voor de Microsoft online diensten gedownload moeten worden. Indien een organisatie momenteel gebruik maakt van BPOS (de voorloper van Office 365) dient naast de installatie van de Service Connector tevens de Single Sign On tool gede-installeerd te worden.

Voor integratie met de Microsoft Office producten dient minimaal gebruik gemaakt te worden van Office 2007 (minimaal SP2) of Office 2010. Office 2003 wordt niet meer ondersteund door Office 365. Voor de Mac worden Office 2008 en Office 2011 ondersteund. Om Lync Online te kunnen gebruiken wordt de Lync Communicator en Communicator for Mac ondersteund.

Microsoft Online ID's of Active Directory Passwords

Om in te kunnen loggen op Office 365 is een inlognaam en wachtwoord nodig. Dit kan een zogenaamde Microsoft Online ID zijn, maar ook een reeds bestaand Active Directory account. In deze laatste variant, een Active Directory account, is de inlog Single Sign On met een lokale omgeving. Indien gebruik gemaakt wordt van Microsoft Online ID's wordt een geheel eigen inlognaam en wachtwoord gebruikt voor het inloggen op de Microsoft Online Services ten opzichte van de inlognaam en het wachtwoord dat gebruikt wordt voor de lokale omgeving.

Het aanmaken van Microsoft Online ID's kan handmatig, door het uploaden van een csv bestand met gebruikers, middels Power Shell (hoewel in de beta nog niet beschikbaar) en via de Microsoft Directory Synchronization Tool. Deze kopieert alle lokale Active Directory accounts naar de cloud. Daar wordt vervolgens een wachtwoord toegewezen aan de gebruikers. De online accounts staan in dat geval dus geheel los van de lokale accounts.

 

De voordelen van het werken met een Microsoft Online ID zijn onder meer dat een lokale Active Directory niet perse noodzakelijk is, het beheer naar andere personen dan de IT afdeling kan worden gedelegeerd en de oplossing direct kan worden ingezet. Het grootste nadeel van het werken met een Microsoft Online ID is dat de inlognaam en het wachtwoord niet gekoppeld of hetzelfde zijn aan de lokale Active Directory. Het wachtwoord, maar ook het wachtwoord beleid en de inlognaam kan dus verschillen tussen de Windows accounts en de accounts voor Office 365. Het risico hiervan is dat extra ondersteuning nodig is voor gebruikers. Met name dat de inlognaam anders is dan de inlognaam voor de lokale computer kan hierbij veel problemen opleveren. Zo is de inlognaam van Office 365 gebaseerd op een UPN (bijvoorbeeld danny.burlage@wortell.nl) en is de inlognaam van een lokale computer veelal gebaseerd op een sAMAccountName.

De meest ideale optie is om te werken met Single Sign On. Om gebruik te kunnen maken van Single Sign On dient een koppeling tussen de lokale Active Directory en de Microsoft Online Directory gemaakt te worden. Deze koppeling wordt gelegd op basis van Active Directory Federation Services (AD FS). Het opbouwen van een AD FS infrastructuur kan voor organisaties die hier nog geen gebruik van maken, een complexe aangelegenheid zijn. Zo dient één, maar naar voorkeur liever minimaal twee, Active Directory Federation Servers opgebouwd te worden. Indien authenticatie buiten het lokale netwerk (dus via het Internet) noodzakelijk is, zal naast de Active Directory Federation Servers echter tevens een AD FS proxy geïnstalleerd moeten worden. Dit zijn nog eens twee extra AD FS servers. Als alternatief is het echter ook mogelijk om de AD FS servers middels UAG, TMG of een andere reverse proxy oplossing te ontsluiten.

Het voordeel van werken met Single Sign On is dat gebruikers zowel voor hun Windows omgeving als voor de Office 365 dezelfde inlognaam en wachtwoord kunnen gebruiken. Daarnaast kan gewerkt worden met 2 Factor Authenticatie. Denk daarbij aan SMS of Token authenticatie. Ten slotte hoeft de gebruiker nooit meer zelf in te loggen. Het grootste nadeel is dat een aparte infrastructuur opgebouwd of ingericht dient te worden voor synchronisatie met Office 365.

Role Based Access

Voor het beheer van Office 365 kunnen verschillende soorten rollen voor beheerders gedefinieerd worden. Elk van deze rollen krijgt meer of minder rechten om beheerswerkzaamheden uit te kunnen voeren. Standaard zijn de volgende rollen beschikbaar:

• Tenant Admin: Is de allerhoogste beheerder. Een gebruiker met deze rechten heeft de mogelijkheid alle instellingen te doen en andere beheerders aan te maken;
• Billing Admin: Heeft volledige toegang tot alle facturatie gegevens (instellen van betaalmethode, downloaden van facturen) en wordt op de hoogte gesteld bij alle communicatie rondom facturatie. Heeft daarnaast leesrechten op de verschillende objecten (gebruikers, domeinen) in de omgeving;
• User Account Admin: Heeft leesrechten op de gehele omgeving en kan gebruikers aanmaken en beheren;
• Help Desk Admin: leesrechten op alle Office 365 objecten (gebruikers, domeinen). Kan daarnaast wachtwoorden opnieuw instellen;
• Service Support Admin: Heeft leesrechten op alle Office 365 objecten (gebruikers, domeinen). Kan daarnaast rechten gegeven worden op afzonderlijke diensten (Exchange Online, SharePoint Online, Lync Online).

Specifiek voor IT dienstverleners die ondersteuning aan een organisatie geven die gebruik maakt van Office 365 zijn twee aparte rollen ingericht, te weten:

• Agent Admin: Heeft volledige rechten op een klantomgeving. Staat gelijk aan een Tenant Admin;
• Agent Help Desk Admin: Staat gelijk aan de Help Desk Admin role. Beheerder heeft rechten om gebruikerswachtwoorden opnieuw in te stellen.

Naast deze Office 365 specifieke beheersrollen is het mogelijk voor de individuele diensten (Exchange Online, SharePoint Online) aparte beheersrollen te definiëren. Dit zijn de standaard beheersrollen zoals ook van toepassing zijn op de "On Premise" producten.

Microsoft Exchange Co-existentie

Exchange Online in Office 365 maakt het mogelijk e-mail in een hybride vorm te gebruiken. Daarbij staat een deel van de mailboxen bij Microsoft in Office 365 en een deel van de mailboxen op een lokale Exchange server. Hoewel BPOS deze mogelijkheid ook bood, zaten er in het co-existentiemodel van BPOS enkele beperkingen zoals de synchronisatie van Free/Busy informatie tussen gebruikers in BPOS en 'lokale' Exchange gebruikers. Office 365 heeft dit nu opgelost. Niet alleen de beperkingen zijn opgelost (zoals Free/Busy informatie), maar het is nu ook mogelijk om vanaf de Exchange Management Console zowel de lokale Exchange Server als de Office 365 Exchange Online omgeving te beheren. Hiermee wordt dus een werkelijk hybride ervaring gecreëerd.

 

Andere functionaliteiten die bij gebruik van een Rich Coexistence scenario worden ondersteund zijn: routering van e-mail tussen online en on premise mailboxen, gebruik van dezelfde domeinnaam (zoals @wortell.nl), dezelfde GAL, delen van Free/Busy informatie, mailtips en Out of Office informatie alsof beide omgevingen dezelfde zouden zijn, het doorsturen van OWA gebruikers afhankelijk van de locatie waar hun mailbox wordt gehost, ondersteuning voor het verplaatsen van mailboxen (tussen de Online, On Premise en vica versa) en het niet hoeven herladen van de OST bestanden indien mailboxen verplaatst worden.

 

Hoewel het gebruik van AD FS is aan te raden in omgevingen waar gebruik gemaakt wordt van Rich Coexistence (zoals Microsoft deze functionaliteit noemt) is dit niet strikt noodzakelijk. Wel dient gebruik gemaakt te worden van Microsoft Directory Synchronization en dient minimaal één Exchange 2010 SP1 HUB/CAS server lokaal in gebruik te zijn.

Aanpasbaarheid Online Diensten

Microsoft heeft er veel werk van gemaakt om de verschillende Office 365 diensten zowel mogelijk aanpasbaar te maken. Naast het beheer en aanpassen van de diensten via de web-omgeving, is het mogelijk om Exchange Online, SharePoint Online en Lync Online aan te passen en te beheren via Web Services, PowerShell en maatwerkoplossingen gebouwd via Visual Studio.

Migreren naar Office 365

Nadat een Office 365 abonnement is afgesloten en de algemene instellingen zijn bepaald, de domeinnamen zijn toegevoegd en een keuze is gemaakt voor authenticatie, dient de omgeving te worden ingericht. Veelal zal het inrichten van de omgeving beginnen met het migreren van een bestaande omgeving naar Office 365. Daarbij gaat het primair om de migratie van e-mail naar Exchange Online en lokale SharePoint omgevingen of documenten op fileshares naar SharePoint Online.

Specifiek voor de migratie van oude Exchange omgevingen, mailsystemen die gebaseerd zijn op IMAP en POP biedt Microsoft als onderdeel van de Office 365 beheer console een set van online Migratie tools aan. Hiermee is het mogelijk een 'oude' e-mail omgeving geheel of gedeeltelijk naar Exchange Online te migreren. Indien gekozen wordt voor een co-existentie scenario is het verplaatsen van Exchange mailboxen die in een lokale omgeving draaien gewoon via de Exchange Management Shell uit te voeren.

Voor het migreren van e-mail vanaf oude Exchange versies en IMAP systemen kan een, relatief eenvoudig, stappenplan doorlopen worden. Als alle instellingen goed zijn gezet is de migratie een redelijk eenvoudige aangelegenheid. Indien in de 'oude' omgeving echter niet alles goed is ingesteld of zich in de 'oude' omgeving problemen voordoen, kan de migratie een stuk complexer zijn en dienen eventueel voorbereidende werkzaamheden uitgevoerd te worden. Een voorbeeld hiervan is dat Exchange Online automatisch e-mail uit oudere Exchange servers kan migreren, mits de AutoDiscover functie goed is ingericht. Indien dit niet het geval is of bijvoorbeeld een certificaat is gebruikt dat niet door een publiekelijk vertrouwde uitgever van certificaten is uitgegeven, zal de migratie niet zomaar uitgevoerd kunnen worden. Een goede voorbereiding voorafgaand aan de migratie van e-mail is dus cruciaal.

De migratie voor bestaande BPOS klanten

Gebruikers van de Business Productivity Online Suite (BPOS) worden automatisch door Microsoft gemigreerd. Alle bestaande klanten krijgen een voorstel van Microsoft voor de datum waarop de BPOS omgeving wordt omgezet naar Office 365. Klanten hebben vervolgens de mogelijkheid om ervoor te kiezen een andere datum voor te stellen. De migratie naar Office 365 gebeurt geheel op de achtergrond en wordt volledig door Microsoft uitgevoerd. Wel dienen klanten zelf ervoor zorg te dragen dat de lokale omgeving aangepast is op de minimale systeemvereisten van Office 365. Daarnaast zullen klanten die veel wijzigingen hebben gemaakt in SharePoint moeten controleren of al deze modificaties daadwerkelijk nog functioneren in SharePoint Online.

Service Descriptions

Hoewel de Office 365 diensten gebaseerd zijn op de "On Premise" producten en grotendeels gelijkwaardig zijn aan deze lokaal geïnstalleerde versies, zitten er toch verschillen in de functionaliteit. Binnen SharePoint Online is bijvoorbeeld de Business Connectivity Services en FAST Search niet beschikbaar, op Exchange online kunnen bijvoorbeeld geen derde applicaties geïnstalleerd worden en Lync Online ondersteund de koppeling met een telefooncentrale niet, in tegenstelling tot de lokaal geïnstalleerde versies van deze producten. Om er zeker van te zijn dat de functionaliteiten die in Office 365 worden aangeboden voldoen aan de wensen en eisen in uw specifieke situatie, is het dan ook aan te raden de Service Descriptions waarin deze verschillen tot in detail zijn beschreven goed door te nemen.

Bekijk de Office 365 Service Descriptions 

Metalogix neemt StoragePoint over #SP2010NL

Wortell en Metalogix hebben inmiddels geruime tijd een partnership. Wortell zet de verschillende Metalogix producten in voor haar SharePoint migraties. Daarbij gaat het met name om migraties naar SharePoint 2010 vanaf SharePoint 2003 of 2007.

StoragePoint is een product waarmee data in SharePoint kan worden opgeslagen buiten de SharePoint SQL Server database. Het gaat daarbij om documenten. Deze gegevens worden opgeslagen op een File System en niet meer in de SQL Server database. Naast het opslaan van documenten op een File System is het echter ook mogelijk de documenten naar cloud oplossingen te verplaatsen zoals Windows Azure.

Grofweg werkt het model als volgt:

In SharePoint 2010 is het tevens mogelijk om documenten in de vorm van Blobs op te slaan op een filesystem. Er zijn echter enkele grote verschillen tussen de mogelijkheden van StoragePoint en de standaard SharePoint 2010 functionaliteiten. Hieronder een uittreksel uit het StoragePoint blog over SharePoint 2010:

You don't need a StoragePoint-like solution with 2010, it will do this OOB.

False: I could give that a partially true, but then I'd be giving credibility to the notion that the RBS FILESTREAM Provider is a viable solution for most enterprises. I firmly believe that it's not and not because I want you to suspend reality and buy our stuff no matter what. I believe that it's not viable because it was not designed, architected or built to address the needs that StoragePoint addresses. It was built to provide a free upgrade path for companies that implemented WSS 3.0 using the WIDE (Windows Internal Database Engine) option. There is no WIDE option for SharePoint Foundation Server, so the only free upgrade is SQL Express which has a 4GB database size limit. The RBS FILESTREAM Provider was built to give these customers a way to remote the BLOBs as they upgraded. Might not work for all of them, but it will work for most.

If you don't fit into the definition above (...WSS3/WIDE upgrade to 2010) then what's the benefit of this option? It's doesn't perform better than leaving the BLOBs in the database. You can't tier storage, or compress BLOBs, or encrypt them. And oh BTW, Microsoft isn't recommending this option for you. They've made the caveats pretty clear in presentations and blog posts that I've seen.

Metalogix heeft een persbericht uitgegeven over de overname:

Metalogix Acquires StoragePoint and dissolves SharePoint Scalability and Performance Boundaries

As you are one of the people we consider influential in the SharePoint community, we wanted to give you this advance notice of some significant news.  Metalogix Software has acquired the StoragePoint product line from BlueThread Technologies.  The official acquisition announcement will become public tomorrow morning, Monday, March 15th, but we are making this news available to you without embargo, so if you wish to make comment, you can write about it today.

I'm sure you've already heard about StoragePoint's amazing customer success stories and that it was the recipient of Microsoft's Innovative SharePoint 2010 ISV Award at the SPC in Las Vegas.

Why the award? Until recently SharePoint has had a one-to-one relationship between the size of the content and the size of the content database.  Larger content databases push SharePoint boundaries and increase SharePoint disaster recovery, indexing,  and maintenance timeframes.  Also, the additional SQL I/O overhead created by the BLOBs necessitates fast hardware in the database tier.  If everything is in the SQL Server database then everything has to be stored on this high end hardware.  StoragePoint eradicates all of these challenges. You can now have 2+ Terabytes of content managed within a single 100GB content database!

StoragePoint accomplishes this dramatic change in SharePoint storage boundaries by leveraging the SharePoint EBS interface in SharePoint 2007 and both the EBS and SQL RBS APIs in SharePoint 2010.  StoragePoint takes all the existing BLOB content out of a customer's SharePoint content databases and keeps new content from ever entering SQL Server in the first place.  The content could be remoted to the same tier of storage as SQL Server or it could be put on less expensive Tier 2 storage, Tier 3 storage, or even pushed up to the Cloud.  You can even cause different types and sizes of content to go to different tiers of storage.   No matter where you put it, you instantly get two benefits.   (1) Your content database size shrinks, making it more responsive, more manageable, and more reliable.  (2) In most cases your file access through SharePoint actually speeds up, especially when dealing with large files and bulk operations (i.e. Crawl).

SharePoint architects will ask, "How can my file access speed up when you're taking the files out of the SharePoint database?"   Good question— and StoragePoint has a great answer: 

There are two parts to this answer, the first being StoragePoint removing a step in the BLOB I/O workflow.  SharePoint natively breaks a document down into chunks on the WFE and sends it to SQL Server for processing where it is then written to the database file.  With EBS or RBS in place, documents are streamed from the WFE to the configured remote storage endpoint.  This form of I/O is much more efficient than the chunking that takes place between the WFEs and SQL Server. With StoragePoint you remove an I/O operation (SQL Server to Disk) and replace an inefficient I/O operation (BLOB Chunk from WFE to SQL Server) with a more efficient I/O operation (BLOB Stream from WFE to Storage Endpoint).  The other part of the answer has to do with the removal of all the BLOB I/O overhead from SQL Server.  SQL Server is left with more resources to manage relational data and transactions, so those types of operations will perform better and are significantly less likely to block…a common problem in many SharePoint implementations where you are dealing with large volumes of content or concurrent user counts.  

What's even better, there's absolutely no sacrifice to functionality or user experience…everything in SharePoint just works faster!. It's also 100% .Net.

If you're wondering how StoragePoint will work for you, just try it yourself.   Starting tomorrow, Monday, you will be able to check out the 30-day free trial of StoragePoint on the Metalogix web site, use it with your data and get rid of your SharePoint boundaries. You can even see "How low you can go" with the BLOBulator, a no cost downloadable utility on our site.  The BLOBulator will estimate the size of your SharePoint content database(s) as if you were using StoragePoint and  it doesn't impact or harm your production system in any way.