Simpelste fake hybride Office 365 on premise constructie

Wij werden recent door een klant benaderd met het probleem dat zij eigenlijk een on-premise omgeving wilde combineren met een Office 365 omgeving. Normaliter zijn hiervoor wel wat routes maar deze vereisen aardig wat complexe configuratie en afstemming. Microsoft heeft hier diverse routes en plannen voor (zie ook de Microsoft site hierover) maar dit gaat veel te diep.

Inleiding

Met on-premise bedoeld Microsoft een omgeving die lokaal draait. In de meest ideale situatie is dit een Exchange platform waarmee een naadloze integratie op te zetten is. Hebben we het echter over een shared hosting server dan wordt het een heel ander verhaal. Waarom zou je dit überhaupt willen?

Stel dat je een organisatie hebt met een tiental mailboxen waarvan er maar 1 of 2 in de cloud terecht hoeven te komen (bijvoorbeeld om licentiekosten te sparen of omdat het gewoon geen zin heeft qua implementatie). Je zou dit liefst natuurlijk naast elkaar doen maar hierover is maar weinig te vinden.

De oplossing

Wij kwamen uiteindelijk na wat gestoei met de volgende oplossing;
Er wordt een regulier Office 365 account aangemaakt conform de normale regels behalve dat de mail primair bij de on-premise locatie blijft binnenkomen. Voor de 1 of 2 gewenste boxen zetten we een forward op naar het @onmicrosoftonline.com adres. Hierdoor komt deze mail daar binnen terwijl de rest bij de primaire server blijft binnenkomen. Uiteraard niet de mooiste oplossing en er zitten best een paar haken en ogen aan.

Zo is het niet mogelijk vanuit de boxen naar andere mailboxen intern te mailen omdat deze, logisch ook, door Microsoft gepoogd worden intern te bezorgen wat niet gaat. Daarnaast geeft deze constructie soms wat verwarring qua waar mail vandaan komt en naartoe moet (spamfilters, reply’s etc.). Echter is het de meest platte oplossing en zeker als het om één box gaat wat ons betreft een prima oplossing.

Zo creëer je eigenlijk heel snel en simpel een fake hybride Office 365 on premise oplossing.

Skydrive synchronisatie problemen

Het kan soms voorkomen dat Microsoft Skydrive stopt met synchronisatie. Hij geeft een minimalistische error zonder een specifiek bestand of map als schuldige te benoemen. Het herstarten van de synchronisatie werkt niet en enige optie lijkt het compleet verwijderen van de gesynchroniseerde map om deze opnieuw aan te maken.

Oplosbare errors

Toch zijn er een paar errors welke nog wel oplosbaar zijn. Sowieso loopt hij eruit bij bestandsnamen die onmogelijke karakters bevatten of te lang zijn – komt voort uit de Sharepoint web-structuur die onderhevig is aan andere technische kaders dan een normaal filesysteem. Zie ook de FAQ hierover op de Microsoft site.

Daarnaast kan het soms voorkomen dat hij een error ondervindt bij het uploaden van een map of bestand wat als gevolg heeft dat de cache defect is. Er is dan geen specifieke plek die fouten geeft maar hij is ook niet meer in staat opnieuw de synchronisatie op te zetten.

Kijk in het overzicht wat de laatste succesvolle synchronisatie was en ga naar
C:\Users\[jouwgebruikersnaam]\AppData\Local\Microsoft\Office\15.0\OfficeFileCache

En verwijder hier de file/files die aangemaakt zijn rondom de tijd van de laatste succesvolle synchronisatie. Met een beetje geluk bespaar je hiermee een complete ontkoppeling en herkoppeling van de synchronisatie.

Office 365 domein verwijderen of aanpassen

Als je in Office 365 de primaire domeinnaam wilt wijzigen of in zijn geheel wilt verwijderen gaat dat niet zomaar. De primaire domeinnaam wordt in Office 365 op diverse plaatsen toegepast en is ‘hard’ gekoppeld. Verwijderen kan pas als hij volledig ontkoppeld is.

Redenen om dit te willen?

Stel dat je organisatie een nieuwe naam, en dus ook domeinnaam, krijgt of dat de persoon die de migratie startte een fout heeft gemaakt in de domeinnaam. Een andere reden, en de reden dat wij dit vandaag deden, is dat iemand een P-pakket* heeft maar heeft gekozen voor het laten beheren van de DNS door Microsoft. Wij gebruiken zelf normaliter de E-pakketten* omdat je hierin altijd zelf de DNS kunt beheren. In een P-pakket* kan dit wel maar als je eenmaal voorbij de wizzard bent is dit niet meer aanpasbaar. De makkelijkste weg leek mij het gehele proces terug te draaien en opnieuw te starten met de juiste configuratie. Hiervoor moest het domein wel eerst ontkoppeld worden.

* Met een P-pakket bedoelen we de licenties voor kleine- en middelgrote bedrijven. Lees meer over de verschillende pakketten

De stappen

Voor het in Office 365 verwijderen of aanpassen van een primaire domeinnaam moet je de volgende stappen doorlopen;

  1. Log in als admin van het account
  2. Klik rechts op ‘bedrijfsgegevens’
  3. Scroll naar beneden bij bedrijfsprofiel en verander het default domein naar het standaaard @microsoftonline account
  4. Verwijderen aliassen van e-mailboxen op dit domein (mits van toepassing)
  5. Ontkoppel eventuele licenties die aan het domein hangen (bijv. voor Lync)
  6. Je kunt nu het domein verwijderen

Het kan zijn dat het toch niet lukt de domeinnaam te verwijderen uit de lijst. Controleer even op alle schermen of er toch niet toevallig een gebruiker, licentie of iets aan gekoppeld is. Spijtig genoeg geeft Microsoft je geen goede informatie over de redenen van het niet kunnen verwijderen. Het kan soms even zoeken zijn. Maar met bovenstaande lijst heb je vaak het meeste al gedekt.

Office 365: Shared calendar (no licence)

Vandaag een leuke vraag gekregen waar ik nog niet direct het antwoord op had. Dit ging om het opzetten van een gedeelde agenda zonder echte ‘gebruiker’ dus bijvoorbeeld een algemene agenda voor een kantoor of iets. Dacht eerst dat ik het moest zoeken in de richting van distribution- of securitygroups maar dit was te diep gedacht. Al snel realiseerde ik me dat dit gewoon eenvoudig te realiseren was met een gedeelde mailbox.

Als eerste maak je via de powershell een gedeelde mailbox aan (in dit geval noemen we hem kantooragenda@bedrijf.nl):


New-Mailbox -Name "kantooragenda@bedrijf.nl" -Alias "kantooragenda" -Shared -primarysmtpaddress "kantooragenda@bedrijf.nl"

Daarna geef je de gewenste gebruikers maximale rechten op deze mailbox. Stel dat de gebruikers met de aliasen ‘henk’ en ‘annie’ toegang moeten krijgen tot deze agenda dan configureer je dit met:


Add-MailboxPermission "kantooragenda" -User "henk" -AccessRights FullAccess
Add-MailboxPermission "kantooragenda" -User "annie" -AccessRights FullAccess

Office 365: Shared mailbox license required

Als Office 365 fans hebben wij de laatste tijd al een hoop gespeeld met de configuratie. Een probleem wat terug blijft komen (en ook erg veel terug te vinden is op het internet) is de vreemde werking van shared mailboxes in combinatie met licenties. De documentatie van Microsoft geeft op meerdere plaatsen zeer helder aan dat een shared mailbox geen licentie nodig heeft. Alleen gebruikers die deze mailbox willen openen moeten een licentie hebben (en mogen geen kiosk-account hebben).

Wat gaat er mis?

Stel je beschikt over een standaard P1 account en je maakt via de powershell een shared mailbox aan. Het lijkt een redelijke tijd goed te gaan maar ergens gaat het bij een hoop gebruikers fout als ze via de OWA proberen de mailbox te benaderen. Je krijgt dan een error ivm. te weinig toegekende licenties. Het rare is sowieso dat hij wel werkt via bijvoorbeeld Outlook 2010 en mails komen er ook gewoon in.

Na gisteren een ruim uur met een zeer vriendelijke medewerker van Microsoft dit probleem te onderzoeken heb ik zojuist als test een gedeelde mailbox opnieuw aangemaakt. Eerder had ik namelijk een beetje soep gemaakt van de mailboxen door ze ook als een user via het Office 365 admin panel aan te maken.

Mogelijke oorzaken

Omdat het via Outlook wel werkt maar via de OWA niet krijg je al vraagtekens. Wie heeft er gelijk en via welke route gaat er gewoon iets mis in het bepalen van licenties. Mijn eerste idee zou zijn dat de OWA een onjuiste manier gebruikt om de licenties te controleren. Waarom anders zouden er zoveel mensen zijn met dit probleem en er geen concrete oplossingen zijn nog. Het lijkt meer een bug dan een echt licentieprobleem te zijn. Daar de Microsoft medewerkers al enkele keren tussen neus en lippen hebben aangegeven dat zij denken dat Office 365 te snel gelanceerd is en nog best wat kinderziektes bevat ga je nog meer in deze richting neigen. Maar tot Microsoft een oplossing heeft wil je natuurlijk nadenken hoe dit probleem mogelijk kan worden omzeild. Enkele theorieen over waarom deze licentieproblemen getriggerd worden zijn:

  • P1 licenties hebben geen security groups (zoals in de E licenties wel het geval is)
    Als hier de oorzaak zit kan het nog wel eens lastig worden dit ooit werkend te krijgen

  • Standaard krijgt een shared mailbox normale quotas mee terwijl hij licentievrij maar 5 GB mag zijn
    Zou eenvoudig oplosbaar moeten zijn maar denk niet dat dit het probleem geeft.

  • Standaard wordt er met het maken van een mailbox ook een useraccount gemaakt in het Office365 panel
    Wat lastiger verhaal maar zou wel logischer zijn inzake het probleem via OWA. OWA loopt over de “office365 lagen” terwijl je lokale Outlook direct op Exchange rechten niveau werkt

Oplossingen?

Nog niet echt al denk ik ook dat dit meer een applicatie probleem is dan een configuratieprobleem aan de gebruikerskant. Ik zal de komende tijd in iedere geval alles kritisch in de gaten houden en nog wat tests uitvoeren en mocht het probleem zich niet meer voordoen bij specifieke configuraties dan zal ik hier zeker een nieuwe blogpost aan wijden.