Friday, January 31, 2014

Office 365 Partner portal onder handen genomen

Het was vandaag een aangename verrassing om de Office 365 Portal te openen en als partner de omgeving van onze klant te beheren. Het eerste wat direct opvalt is dat de klanten die het beheer aan ons gedelegeerd hebben direct in een lijst zichtbaar zijn, dit werkt een heel stuk prettiger dan het domein handmatig in moeten typen.

image

Wanneer je een klant selecteert dan kun je direct doorklikken naar het Office 365, Exchange, SharePoint of Lync admin center. Klikken we in plaats daarvan op Service Requests of Service Health in het linkerpaneel dan zien we ook direct alleen datgene wat van toepassing is op de omgeving van deze klant.

Al met al een hele verbetering van dit deel van de Office 365 Portal!

Tuesday, January 28, 2014

Office 365 en Windows Azure AD beheren met PowerShell

Microsoft heeft de afgelopen jaren beslist niet stilgezeten als het gaat om het beheer van Office 365. De moderne webinterface biedt veel functionaliteit, is consistent vormgegeven over de verschillende gebieden en is duidelijk genoeg om snel je weg in te vinden.

image

Toch zijn er legio redenen te bedenken waarin je toch graag toegang wilt krijgen met PowerShell, bijvoorbeeld om zaken in te stellen die niet in de webinterface kunnen of om herhalende taken uit te voeren. Denk bijvoorbeeld aan het automatisch toewijzen van licenties aan nieuwe gebruikers.

Als we SharePoint Online en Lync Online even buiten beschouwing laten dan spreken we eigenlijk over twee verschillende PowerShell omgevingen. Als eerste is er Exchange Online PowerShell, hier kunnen we onder andere het volgende mee doen:

  • (Shared) mailboxen aanmaken of wijzigen
  • Rechten op mailboxen aanpassen
  • Etc.

En dan is er nog de Windows Azure AD PowerShell Module, voorheen bekend als Microsoft Online PowerShell Module. Dat laatste zie je nog terugkomen in de naam van de cmdlets, die bevatten allemaal de string ‘msol’. Hiermee kunnen we onder andere de volgende zaken regelen:

  • Toevoegen van een domein aan Office 365
  • Domein omzetten naar federated of stand-alone
  • Licenties toewijzen aan gebruikers

In de praktijk is het handig om een eenvoudig PowerShell script op je computer te hebben staan die verbinding maar met zowel Exchange Online als Azure AD. Hiermee kun je dan altijd alle werkzaamheden uitvoeren.

We starten met het installeren van de Windows Azure AD Module, die op zijn beurt afhankelijk is van de Microsoft Online Services Sign-in Assistant. Een link naar beide downloads vind je hier: Manage Windows Azure AD using Windows PowerShell.

Vervolgens sla je het volgende script op als .ps1-bestand op je eigen computer. Wijzig de UPN in die van je Office 365 beheeraccount, dit spaart je wat typewerk omdat je alleen nog je wachtwoord hoeft in te voeren als daar om gevraagd wordt:

Function Vraag-Credentials
{
$Global:Cred = Get-Credential -Credential beheerder@tenant.onmicrosoft.com
}

Function Verbind-AzureAD
{
Connect-MsolService  -Credential $Cred
}

Function Verbind-ExchangeOnline
{
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://outlook.office365.com/powershell-liveid/ -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession $Session
}

Import-Module msonline
Vraag-Credentials
Verbind-AzureAD
Verbind-ExchangeOnline

Voordat je een niet-ondertekend script kunt draaien kan het nodig zijn om je computer hier eerst voor te configureren: Set-ExecutionPolicy Unrestricted

Wanneer je dit script uitvoert krijg je een PowerShell sessie waarin je zowel Azure AD als Exchange Online voor deze Office 365 omgeving kunt beheren.

Friday, January 24, 2014

Mailbox quota instellen in Office 365

Click here for full size image

Je kunt wel zeggen dat het instellen van mailbox quota vooral iets van de vorige eeuw is, toen een harddisk nog 2,1 GB groot was en evenveel kostte als wat je nu voor een entry-level server betaalt. Vooral als het gaat om Office 365 waarbij je tegenwoordig zelfs bij het goedkoopste abonnement als een 50 GB mailbox krijgt.

Toch is er nog een situatie waarin je toch een mailbox quotum in wilt stellen, namelijk bij de speciale ‘shared mailbox’. Een shared mailbox is een speciale mailbox waar geen Office 365 of Exchange Online licentie voor nodig is. Je geeft vervolgens één of meerdere gebruikers (die wel een licentie hebben) toegang tot deze gedeelde mailbox.

De enige beperking die hier aan zit is dat deze mailbox maximaal 10 GB groot mag worden, als de mailbox groter wordt dan is een Exchange Online 1 of 2 licentie nodig. En hier komen mailbox quota dus weer in beeld. Normaal gesproken kun je dit eenvoudig instellen in het Office 365 Exchange Admin Center:

image

Helaas ontbreekt in Office 365 de knop ‘More options’ waar naar verwezen wordt, je kunt dit in Office 365 blijkbaar niet in EAC instellen: “These settings aren’t available in the EAC in Exchange Online.” Dat betekent dat we terugvallen op de ‘ouderwetse’ Exchange Management Console. Om te beginnen maken we een remote PowerShell sessie met Exchange Online:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

Vervolgens kunnen we net als in een on-premises omgeving de storage quota’s instellen:

Get-Mailbox -Filter { RecipientTypeDetails -eq "SharedMailbox" } | Set-Mailbox -ProhibitSendReceiveQuota 10GB -ProhibitSendQuota 9.75GB -IssueWarningQuota 9.5GB

Als we klaar zijn ruimen we de sessie weer op:

Remove-PSSession $Session

imageOp deze manier hebben we dus een mailbox quotum van 10 GB ingesteld op alle gedeelde mailboxen in onze Office 365 organisatie.

Thursday, January 9, 2014

ADFS op een domain controller, goed idee?

Met de opkomst van Office 365 rollen steeds meer organisaties Microsoft Active Directory Federation Services (ADFS) uit in hun omgeving. Voor de meeste mensen gaat het hier om nieuwe techniek die meestal ook nog eens gelijk komt met directory synchronisatie en nog maar de start is van een ingewikkeld migratietraject. Er leven dan ook nogal wat vragen rondom ADFS en één daarvan is of het een goed idee is om ADFS op een domain controller te installeren. In dit artikel wil ik hier uitleg over geven.

Waarom wel?

Het combineren van lichte rollen werd lang als best practice beschouwd, op deze manier werd zo efficiënt mogelijk gebruik gemaakt van de dure hardware en Windows Server licentie. Het installeren van ADFS op een domain controller vermindert dus het aantal servers.

Omdat Microsoft het adviseert voor organisaties met minder dan 1000 gebruikers: “For the federation servers, use two existing Active Directory domain controllers (DCs) and configure them both for the federation server role.” Waarom die grens van 1000 gebruikers, wat gebeurt er als je 1200 gebruikers hebt? Dit getal moet niet gezien worden als een harde norm maar je kunt wel uit het artikel afleiden dat Microsoft deze opstelling adviseert wanneer het moeilijk is om de inzet van dedicated servers te rechtvaardigen.

Domain controllers staan altijd aan en iedere beheerder weet dat deze server belangrijk is voor de werking van de Active Directory omgeving en vrijwel alle services in het netwerk. Als je ADFS ook op deze server zet dan wordt die waarschijnlijk met dezelfde zorg behandeld.

En waarom dan niet?

Tegenwoordig zijn de kosten per Windows server sterk gedaald, door virtualisatie draaien er meerdere servers op een fysieke host en de licentie is al gekoppeld aan de fysieke server. Hoe meer virtuele Windows Servers, hoe lager de kosten per server.

ADFS servers worden dubbel uitgevoerd, net als domain controllers, maar hebben wel load balancing nodig. Wanneer je kiest voor WNLB dan is het doorgaans nodig om een extra netwerkadapter toe te voegen. Dat is iets wat je op een domain controller zeker niet wilt doen.

Of omdat Microsoft het afraadt voor gebruik in productie: “Because ADFS requires the installation of Internet Information Services (IIS), we strongly recommend that you not install any ADFS components on a domain controller in a production environment.” Dit geldt weliswaar voor Server 2003 maar is ook van toepassing op ADFS in Server 2008, 2008 R2 en Server 2012.

Bij gecombineerde rollen gaat het niet alleen om ADFS. In de praktijk zien we op de domain controller nog tal van andere taken, zoals Certificate Authority, (Terminal Server) KMS/Licensing server, Citrix licensing of zelfs Exchange. Bij onderhoud, troubleshooting of in geval van disaster recovery werkt het een stuk makkelijker als een server slechts een taak heeft. Zo kan het wel eens wenselijk zijn om een problematische domain controller geforceerd uit AD te halen en daarna de metadata op te schonen. Probeer dat maar eens als er nog allerlei andere taken op de server draaien.

In de aanbevolen configuratie wordt met ADFS ook de Windows Internal Database geïnstalleerd. Hiermee neemt het aantal te installeren updates toe en dus de algemene beheerlast. Niet alleen de security footprint neemt hiermee toe, maar je vergroot ook het attack surface. Iets wat je zeker niet welkt met de server waarop de complete security databases van je domain is ondergebracht.

Dus?

Mijn advies is om ADFS op minimaal twee dedicated servers te installeren. Minimaal één server dus en extra server voor redundancy, daarboven heb je een ADFS server nodig per 15.000 gebruikers. Gebruik dan naar wens WNLB om de servers te load balancen of beter, gebruikt een echte load balancer die ook het gezond functioneren van de servers in het oog houdt.

En als het echt op een domain controller moet dan heeft ADFS 3.0 uit Windows Server 2012 R2 de voorkeur omdat deze niet meer afhankelijk is van IIS.

Monday, January 6, 2014

Hoe zit dat nu met Office 365, DirSync en de UPN?

Onlangs schreef Jethro Seghers, een Belgische Office 365 MVP een artikeltje met de titel How to allow DirSync to synchronize a .local domain without a domain rename. De schrijver stipt een belangrijk aspect aan waar veel mensen mee te maken krijgen bij een Office 365 implementatie. Alleen ontbreekt in het artikel een stukje context en is de term ‘domain rename’  wat ongelukkig gekozen. Met deze blogpost wil ik uitleggen wat het issue werkelijk is en waarom een domain rename hier eigenlijk niets mee te maken heeft.

Wat is een UPN eigenlijk?

De User Principal Name (UPN) is een Active Directory attribuut in de vorm van een e-mailadres. De waarde voor userPrincipalName hoeft niet altijd gevuld te zijn, het is gewoon een eigenschap van het object zoals ook de cn, name, distinguishedName, en objectGUID attributen dat zijn.

Een UPN bestaat uit een prefix en een suffix, beide delen worden gescheiden door een apenstaartje (@). De UPN wordt ook wel eens internetstijl inlognaam genoemd omdat deze lijkt op een e-mailadres.

In Office 365 wordt de UPN gebruikt om mee aan te melden, dus niet een vorm zoals bijvoorbeeld domein\gebruiker.

Belangrijk om te weten is dat gebruikers een expliciete en een impliciete UPN hebben. Om met die laatste te beginnen, een gebruiker kan altijd aanloggen met zijn impliciete UPN: UserName@dnsdomainname. Dus ook als het userPrincipalName attribuut niet gevuld is.

Een expliciete UPN is een extra UPN die je zelf in kunt stellen door het userPrincipalName attribuut te vullen. Hierbij kun je zowel de prefix als de suffix zelf bepalen. Laten we eens naar een voorbeeld kijken:

image

De impliciete UPN van deze gebruiker is dus Henk@lab1.local en de gebruiker kan hiermee op een AD werkplek aanmelden. Vervolgens stellen we een expliciete UPN in, in het veld userPrincipalName overschrijven we Henk@lab1.local met fiets@banaan:

image

Met deze extra UPN kan de gebruiker nu dus ook aanloggen:

image

Ik heb in dit voorbeeld bewust gekozen voor een rare UPN Suffix. We zijn dus niet beperkt tot eventuele extra suffixes die we in het domein aan kunnen maken volgens: HOW TO: Add UPN Suffixes to a Forest. De suffixes die we hier toevoegen verschijnen vervolgens in de drop-down list in Active Directory Users and Computers (ADUC):

image 

Wat heeft DirSync daar mee te maken?

DirSync is de gratis FIM 2010 implementatie die Office 365 klanten mogen gebruiken om hun AD-objecten naar Windows Azure AD te synchroniseren. Voordat je deze inschakelt moeten de te synchroniseren AD objecten aan een aantal eisen voldoen. Zo mogen er bijvoorbeeld geen ongeldige karakters in de AD velden staan en moet de UPN aan het volgende voldoen:

Your Active Directory environment must be properly configured in order for your users to sign-in to Microsoft online services. In particular, the userPrincipalName (UPN) attribute, also known as a user logon name, must be set up correctly for each user in a specific way. The UserPrincipalName attribute must use a publically routable domain.  If you are not currently using a publically routable domain, you will need to update your users UserPrincipalNames.  To do this, add an alternative UPN suffix in your on-premises Active Directory.

Zo kunnen we lezen in Prepare for directory synchronization. De reden hiervoor is dat je gebruikers met hun UPN moeten aanmelden bij de Office 365 diensten, aan de hand van de UPN suffix wil Microsoft dan kunnen bepalen of je een ook een wachtwoord in moet geven of dat je organisatie gefedereerd is en er een redirect naar een ADFS-server moet worden gegeven.

Wat nu als mijn UPN niet voldoet?

Zo komen we weer bij het probleem uit het artikel wat ik eerder aanhaalde. Wat nu als mijn DNS domein naam op .local eindigt? Dan voldoet de impliciete UPN dus niet aan de eisen omdat deze eindigt op @domain.local. Dan voegen we daar dus een expliciete UPN aan toe die wel een ‘publically routable name’ heeft. Dan kan dus door een suffix toe te voegen aan ADUC en deze per gebruiker te kiezen, door het userPrincipalName attribuut voor iedere gebruiker te bewerken met ADSIEdit of ADUC of natuurlijk scriptmatig.

Er zijn een aantal mogelijkheden om dit te doen, bijvoorbeeld met de native Server 2012 AD cmdlets:

Get-ADUser -Filter { UserPrincipalName -like "*@lab1.local"} |
ForEach-Object {
$UPN = $_.UserPrincipalName.Replace("lab1.local","office365lab.com")
Set-ADUser $_ -UserPrincipalName $UPN
}

Welke UPN deel ik uit?

Goed, we hebben aan gebruiker Henk nu uitgelegd dat hij mag inloggen met henk@office365lab.com want dat is zijn username met de nieuwe UPN suffix. Maar Henk had ook al een mailadres die daar op lijkt: h.steen@office365lab.com. Als we dan toch een nieuwe UPN moeten geven aan de gebruikers, zou het dan niet handig zijn om die gelijk te maken aan het primaire SMTP adres? Het is voor gebruikers namelijk makkelijker te onthouden dat ze bij Office 365 in kunnen loggen met hun mailadres.

Een script om dit uit te voeren zou er zo uit kunnen zien:

Get-ADUser -Filter { UserPrincipalName -like "*@lab1.local" } -Properties mail |
ForEach-Object {
Set-ADUser $_ -UserPrincipalName $_.mail
}

En wat als ik te laat was?

Als de UPN niet aan de eisen voldoet wordt het object wel gesynchroniseerd maar krijgt hij een UPN in je Office 365 standaard domein: tenant.onmicrosoft.com. Daar kunnen we niet mee inloggen dus dit moet veranderd worden in de juiste UPN.

Hiervoor gebruiken we de Windows Azure AD PowerShell cmdlets: Windows PowerShell-cmdlets gebruiken om uw Windows Azure AD-tenant te beheren Eenmaal verbonden kunnen we de UPN opnieuw instellen met het Set-MsolUserPrincipalName cmdlet. Bijvoorbeeld:

Get-MsolUser henk@lab1.local | Set-MsolUserPrincipalName –NewUserPrincipalName henk@office365lab.com

Tenslotte

Als we op deze manier naar de UPN kijken dan is duidelijk dat het hernoemen van je domein nooit een optie geweest is, dat is dus ook niet het probleem wat we op hoeven te lossen. Wel kan het zijn dat je pas later in het proces tegen dit onderwerp aanloopt en hierdoor verrast wordt. Dit kun je voorkomen door je implementatie te plannen en uit te voeren aan de hand van de documentatie op TechNet:

Inmiddels heb ik de auteur van het artikeltje via Twitter gesproken, hij heeft de naam van het artikel al aangepast en de term ‘without a domain rename’ laten vervallen. Bovenstaand artikel is hiermee gelijk wat minder relevant geworden maar ik hoop dat het alsnog wat bijdraagt.