dinsdag 16 september 2014

Exchange 2013 en meerdere OWA/ECP virtual directories

Soms kunnen er redenen zijn om op één Exchange 2013 CAS server meerdere /owa (en bijbehorende /ecp) virtual directories te hebben. Bijvoorbeeld voor één van de volgende scenario's.

Afwijkende authenticatie-instellingen

Interne gebruikers landen voor OWA op de /owa virtual directory op de CAS server. Forms-based Authentication (FBA) is geconfigureerd gebruiksvriendelijk in te kunnen loggen op de webpagina.
Externe gebruikers benaderen OWA via een reverse proxy, bijvoorbeeld een KEMP LoadMaster, Forefront TMG of UAG server.

Gebruikers authenticeren tegen de reverse proxy met een webpagina, de reverse proxy gebruikt deze credentials vervolgens om tegen Exchange te authenticeren. De reverse proxy vereist dat Basic authentication ingeschakeld is op de /owa en /ecp virtual directory.
image

Beheerinterface

Een organisatie vereist dat beheerinterfaces niet vanaf het internet beschikbaar is, intern moeten alle mogelijkheden wel volledig benut worden. Het op de reverse proxy blokkeren van /ecp is geen optie omdat normale gebruikers die virtual directory ook benaderen om hun eigen persoonlijke instellingen te configureren.

Het is mogelijk om toegang tot het beheerdeel, het Exchange Admin Center, uit te schakelen op virtual directory niveau:

Set-ECPVirtualDirectory -Identity "InternalCAS\ecp (default web site)" -AdminEnabled $false

Verkeer vanaf internet zou dus op een /ecp virtual directory moeten landen waarbij het EAC uitgeschakeld is, voor intern verkeer zou deze functionaliteit wel beschikbaar moeten zijn.

Segmentatie

Een derde voorbeeld is de noodzaak voor segmentatie, dat is het in- of uitschakelen van bepaalde functionaliteit. Net als bij de voorgaande twee scenario's is dit iets wat je per virtual directory instelt. Bijvoorbeeld om toegang tot functionaliteit voor een bepaalde groep gebruikers uit te schakelen:

Set-OwaVirtualDirectory -Identity "Contoso\owa (default Web site)" -InstantMessagingEnabled $false -PublicFoldersEnabled $false -ActiveSyncIntegrationEnabled $false

Meerdere sites of meerdere servers?

Een manier om aan bovenstaande eisen te voldoen is een CAS server uit te rollen voor elk scenario. Omwille van redundantie worden dat uiteraard twee CAS servers, dus om zowel OWA met als zonder IM client aan te kunnen bieden hebben we vier CAS servers nodig:


image


Op Exchange 2007 en 2010 was een alternatief, namelijk het aanmaken van één of meerdere extra /owa virtual directories. Zie bijvoorbeeld de volgende artikelen:

Supportability for multiple OWA/ Exchange Web Sites on Client Access Servers in Exchange Server 2007 and Exchange Server 2007 Service Pack 1
Configuring Multiple OWA/ECP Virtual Directories on Exchange 2010 Client Access Server

Exchange 2013

Vreemd genoeg is het plaatsen van dedicated CAS servers momenteel de enige door Microsoft ondersteunde manier om dit te doen met Exchange 2013. En dat is raar, want de methode voor Exchange 2010 werkt ook in Exchange 2013. En de noodzaak voor een dergelijke opstelling is er nog onverminderd, zie ook diverse discussies over dit onderwerp in de communities:

Multiple owa sites on a single server 2012 with exchange 2013 (mailbox, cas)
Exchange 2013, multiple IIS OWA sites with different authentication
Enable second OWA site with form based authentication

Maar wacht even, zei ik dat het werkte? Bij een klant van mij die ik overgenomen hebt draait een dergelijke opstelling al om zowel Basic als FBA aan te kunnen bieden. Dit werkte goed totdat CU5 werd geïnstalleerd, nu wil de tweede /owa geen Basic authentication meer aanbieden maar alleen FBA. En dan zit je dus "mooi" in een niet-ondersteunde situatie, heel vervelend.

Inmiddels heb ik wat lijntjes uitgegooid om een formele uitspraak van Microsoft te krijgen. Wetende dat mijn klant niet de enige is die dit scenario ingericht heeft en de noodzaak er overduidelijk is lijkt het mij goed dat er snel een duidelijke uitspraak komt. Ofwel dat dit ondersteund is, ofwel een bevestiging dat dit niet zo is alhoewel het ontbreken van het eerste ook al zodanig geïnterpreteerd kan worden.

Tot die tijd raad ik aan om dit scenario niet te implementeren tenzij je gedekt bent door Premier Support of anderszins weet dat je ondersteund bent. Zodra ik meer weet laat ik dit zeker horen.

vrijdag 12 september 2014

Google Chrome 37 en Exchange: 9 vragen en antwoorden

Gisteren schreef ik over een paar features in Exchange 2013 EAC die niet meer werken in Chrome 37. Inmiddels zie ik ook berichten van mensen waarbij bepaalde knoppen in Exchange 2010 OWA niet meer werken, dit blijkt te herleiden naar dezelfde oorzaak. In dit artikel leg ik uit wat het probleem is, schets de context en leg uit of we hier wat aan kunnen doen.

Wat is het issue dan?

Microsoft maakt in OWA en ECP/EAC gebruik van de showModalDialog method, deze methode wordt gebruikt om een dialog box te openen met daarin een specifieke HTML-pagina. Voorbeelden van plaatsen waar deze methode gebruikt wordt zijn de From: en To: buttons in OWA 2010 en het + en potlood icoon in Exchange 2013 EAC. Het volgende scherm is een voorbeeld van een dialog box die op deze manier wordt aangeroepen:

image

In Chrome 37 werkt de showModalDialog method niet meer en verschijnen deze dialog boxes dus niet. Overigens raakt dit niet alleen Microsoft applicaties zoals Exchange, SharePoint en Dynamics maar ook verschillende producten van andere leveranciers en een grote hoeveelheid (interne) websites die van deze methode gebruik maken.

Waarom werkt dit niet?

De ontwikkelaars van Google Chrome hebben er voor gekozen om showModalDialog standaard uit te schakelen in Chrome 37. In een volgende release zal showModalDialog compleet verwijderd worden.

Zou het moeten werken?

Als je het aan de ontwikkelaars van Chrome vraagt dan wordt uitgelegd dat deze feature ooit in IE4 zat en sindsdien is bijgehouden in andere browsers maar eigenlijk nooit had mogen bestaan. Als je het aan Microsoft vraagt dan zullen die antwoorden dat ze Chrome 37 ondersteunen als client voor OWA in de premium versie:

image

Waarom is deze keuze gemaakt?

Volgens de ontwikkelaars van Blink, de rendering engine van Chromium waar ook Chrome op gebaseerd is, kost het bijhouden van deze methode erg veel moeite, de code is erg complex geworden en er zijn afhankelijkheden van andere twijfelachtige code. Verder is een kenmerk van deze methode dat hij a) een pop-up geeft, wat niet goed werkt op mobiele platformen en b) de rest van de browser bevriest zolang de pop-up actief is. Dit heeft zelfs al tot een aantal security vulnerabilities geleid.

Als deze methode maar weinig gebruikt wordt en uiteindelijk geheel uit de code verwijderd kan worden dan zou dat veel voordeel brengen voor de programmeurs.

Sinds wanneer?

Aangezien het lijkt dat de hele wereld, inclusief Microsoft, verrast is door deze aanpassing is het goed om eens naar de tijdlijn te kijken. In oktober 2013 is onder Chromium ontwikkelaars voorgesteld om een teller toe te voegen om het gebruik van showModalDialog te meten en een waarschuwing te geven aan website-ontwikkelaars. Hiermee wordt showModalDialog 'deprecated' verklaard, ofwel een feature die uitgefaseerd gaat worden. Op 1 oktober 2013 is dit voorstel verwerkt in de code en op 10 april 2010 beland in de Chrome 35 Beta. Op hetzelfde moment is aangekondigd om showModalDialog in Chrome 36 geheel te verwijderen.

Door het toevoegen van de teller werd vastgesteld dat slechts 0,006% van de pageviews deze methode gebruikt:

image

Voor de ontwikkelaars werd dit gezien als bevestiging dat bijna niemand dit gebruikt. In de hierop volgende discussie kwam er wel wat tegengas maar werd er vooral met het voorstel ingestemd. Ik betwijfel of iemand zich realiseert hoe groot de impact is om de functionaliteit van 0,006% van de pageviews stuk te maken, heeft iemand dat percentage omgerekend naar absoute aantallen? Is er een inventarisatie gemaakt van bekende applicaties die in deze categorie vallen om de impact beter te kunnen begrijpen?

De definitieve versie van Chrome 35 verscheen op 20 mei van dit jaar, Chrome 36 volgde al op 16 juli en Chrome 37 een maand later, op 26 augustus. In tegenstelling tot wat eerder aangekondigd was is showModalDialog in Chrome 36 nog steeds aanwezig maar in 37 is deze uitgeschakeld. In verschillende blogposts is de keuze om showModalDialog te verwijderen verder toegelicht en beargumenteerd.

Uitgeschakeld of verwijderd?

In Chrome 37 is de feature uitgeschakeld maar weer in te schakelen tot 15 mei 2015, daarna wordt de feature echt verwijderd. En hier wordt het interessant. Chrome kent een policymodel waarmee bepaalde features geconfigureerd kunnen worden, bedoeld om Chrome geschikt te maken voor de zakelijke markt. We kunnen de policy EnableDeprecatedWebPlatformFeatures gebruiken om een uitgefaseerde maar nog niet verwijderde features weer aan te zetten.

Hoe zet ik het weer aan?

Met (een elevated instance van) PowerShell zouden we dit als volgt doen:

New-Item HKLM:\SOFTWARE\Policies\Google\Chrome\EnableDeprecatedWebPlatformFeatures
Set-ItemProperty HKLM:\SOFTWARE\Policies\Google\Chrome\EnableDeprecatedWebPlatformFeatures 1 ShowModalDialog_EffectiveUntil20150430 -type string

image

Bij het testen van deze code bleek HKLM:\SOFTWARE\Policies\Google\Chrome op mijn computer niet te bestaan:

image

En ook na het handmatig toevoegen van de hyve bleek de instelling niet doorgevoerd te worden in Chrome, zo bevestigd een bezoek aan chrome://policy/.

Om te begrijpen waarom moeten we weer even terug naar het ontwikkelproces van Chrome. De policies konden nu geconfigureerd worden door middel van registry keys of een GPO policy template. Nadat Chrome registry keys ging gebruiken om de configuratie te managen bleek al snel dat deze registry settings ook aangepast konden worden door andere programma's, denk bijvoorbeeld aan malware. Als reactie ging Chrome 28 de registry keys negeren en kon alleen nog het GPO template gebruikt worden om Chrome te configureren. Wat uiteraard tot veel klachten leidde van beheerders die geen AD gebruiken, geen GPO's of beheer standaard op basis van registry keys uitvoeren.

De verandering in Chrome 28 werden nu deels teruggedraaid en vanaf Chrome 35 worden de registry keys ook weer gebruikt, alleen als de computer lid is van een Active Directory domein.

Wat nu dan?

Beheerders van werkplekken in een AD domein kunnen de registry key of het GPO template gebruiken. Voor losstaande werkplekken kan de GPO template ook in de Loacal Group Policy (gpedit.msc) gelezen worden:

  1. Download de policy templates hier.
  2. Open gpedit.msc en ga naar "Computer Configuration" -> rechtsklik "Administrative Templates" -> "Add/Remove templates" -> klik "Add..." -> selecteer "windows/adm/en-US/chrome.adm" uit de policy_templates.zip download
  3. In "Computer Configuration" -> "Administrative Templates" -> "Classic Administrative Templates" -> "Google" -> "Google Chrome" configureer je nu de policy settings.
  4. Open nu Chrome en ga naar chrome://policy/, hier moet de aangepaste policy nu zichtbaar zijn.

Ontwikkelaars van website zullen alle instances van showModalDialog moeten vervangen door een alternatief.

Wat vinden we hier van?

Het hele verhaal roept de vraag op in hoeverre Chrome klaar is voor de zakelijke markt. De razendsnelle ontwikkelingscyclus van dit open-source project verrast beheerders en ontwikkelaars van websites door features uit te schakelen. Hetzelfde geldt voor het uitschakelen van het beheer door middel van registry keys, zoiets kun je niet doen zonder de zakelijke markt zorgvuldig te informeren en een alternatief te bieden.

Maar ook de afwezigheid van Microsoft in deze discussie valt op. Bij mijn onderzoek viel me op dat er uitgebreide discussies plaatsvinden en hebben gevonden binnen de Chromium, Chrome en Opera communities maar ook bij Mozilla Firefox waar de zelfde discussie speelt. Is er dan geen enkele developer bij Microsoft geweest die zich realiseerde dat zijn applicatie volop gebruik maakt van deze feature? En dat juist nu Microsoft OWA duidelijk positioneert als de primaire client om te werken met e-mail.

Zakelijke klanten zullen zich afhankelijk van hun contract tot Premier Support richten of een case openen via de reguliere supportkanalen. Gebruiker van Office 365, ofwel hun beheerders, kunnen een support request openen In het Office 365 admin center. Ik verwacht een bericht op het Exchange Team Blog één dezer dagen en volg de discussies in de communities met veel interesse.

Geen updates kunnen selecteren in Server 2012 R2

Op een aantal Server 2012 R2 servers valt mij het volgende issue op. In het Windows Update scherm klik op je op het aantal important of optional updates, normaal gesproken verschijnt nu de lijst met updtaes die je kunt selecteren, de-selecteren, verbergen of links voor meer informatie aanklikken. In dit geval gebeurt er niets.

image

Een work-around is om in het linker deel op Change settings te klikken en vervolgens op Cancel. Dan eindig je uiteindelijk hier, het scherm waarin we updates kunnen selecteren:

image

Een irritant probleempje met gelukkig een eenvoudige work-around.

donderdag 11 september 2014

LoadMaster VLM-10G het nieuwe vlaggenschip van KEMP

Nog niet zo heel lang geleden had KEMP Technologies de LoadMaster VLM-100 en VLM-1000 in het portfolio. De bekende LoadMaster software die nu op virtuele hardware kon draaien. Inmiddels bestaan de virtuele load balancers voor onder andere Hyper-V, VMware, KVM, Xen, Oracle VirtualBox en cloudplatformen als Microsoft Azure, VMware vCloud Air en Amazon Web Services.

Enige tijd geleden zijn deze oudgedienden vervangen door de (nu 64-bits) VLM-200 en VLM-2000 en is de VLM-5000 toegevoegd voor nog zwaardere omgevingen. Alle edities beschikken over dezelfde software als de fysieke uitvoeringen en updates zijn beschikbaar voor alle klanten met een geldig supportcontract, nieuwe features zijn er dus voor organisaties die net een nieuwe load balancer aangeschaft hebben maar ook voor een oudere VLM-1000.

Om ook een antwoord te hebben voor de meest veeleisende toepassingen is daar nu de VLM-10G aan toegevoegd waarbij 10G voor een maximale doorvoer van 10.000 Mbps staat. De VLM-10G ondersteunt tot 12.000 SSL TPS. Met de komst van dit nieuwe vlaggenschip is de prijs van de VLM-5000 verlaagd, goed nieuws voor klanten die de ruwe power van de VLM-10G niet nodig hebben maar net wat meer verlangen dan de VLM-2000.

Hiermee bestaat het aanbod aan virtuele load balancers nu uit de volgende uitvoeringen:

Model

VLM-200

VLM-2000

VLM-5000

VLM-10G

 
Doorvoer (licentie)

200 Mbps

2 Gbps

5 Gbps

10 Gbps

SSL TPS (licentie)

200

1.000

10.000

12.000

Voor allemaal geldt dat ze over het Edge Security Pack beschikken, de reverse proxy functionaliteit die bedoeld is om Forefront TMG te kunnen vervangen, en de Geo Load Balancing add-on ondersteunen. Interessante ontwikkelingen!

clip_image001

KEMP technologies levert sinds 2000 betaalbare load balancers met enterprise features. Imara ICT is KEMP Authorized Partner en heeft ruime ervaring met de levering en implementatie van KEMP LoadMaster producten. Neem contact op voor meer informatie of een vrijblijvende aanbieding.

Werken met (legacy) Public Folders

Op dit moment heb ik het genoegen om te mogen werken met een grote hoeveelheid Public Folder data. Het doel is om deze te repliceren naar nieuwe databases. Hierbij gebruik ik een aantal scripts en tools die misschien handig zijn om te delen.

Overzicht

Als eerste heb ik een Excel-file gemaakt met een overzicht van alle folders, het aantal items hierin en de grootte in MB. Dit is weliswaar een momentopname maar het geeft je een goed beeld van de structuur en de grootste folders.

Get-PublicFolder -Recurse -ResultSize Unlimited | Get-PublicFolderStatistics | Select-Object Name,FolderPath,CreationTime,LastAccessTime,LastModificationTime,LastUserModificationTime,LastUserAccessTime,@{expression={$_.totalitemsize.value.ToMB()};label=”Size(MB)”},ItemCount | Export-CSV "C:\data\pfstats.csv"

Denk aan de -ResultSize parameter, anders krijg je met Get-PublicFolder alleen de eerste 10.000 resultaten. Dit bestand heb ik in Excel geopend, conditional formatting gebruikt om folders met veel items of data snel te kunnen herkennen en uiteraard opgeslagen als xlsx-bestand.

Aan de hand van dit bestand heb ik de top-level folder kunnen kiezen waarmee ik de replicatie wil starten. Ook heb ik kolommen toegevoegd voor de nieuwe databases zodat ik een check kan zetten als ik deze als replica toegevoegd heb. Dit helpt mij om overzicht te houden gedurende het proces.

Replica's toevoegen of verwijderen

Op de locatie waar Exchange geïnstalleerd is staat een \scripts directory. Omdat het installatiepad per server verschilt is er de $exscripts een variabele die we in Exchange Management Shell kunnen gebruiken om de scripts te lokaliseren.

image

In dit geval gebruik ik het AddReplicaToPFRecursive.ps1 script om de nieuwe database als replica toe te voegen op een toplevel folder en alle onderliggende folders:

cd $exscripts
./AddReplicaToPFRecursive.ps1 -TopPublicFolder "\MyFolder" -ServerToAdd NewServer1

Op een later moment gebruik ik het RemoveReplicaFromPFRecursive.ps1 om de oude replica te verwijderen. Een alternatief zou het gebruik van het MoveAllReplicas.ps1 script die beide stappen in één keer doet. Meer informatie over deze scripts vind je hier: Scripts for Managing Public Folders in the Exchange Management Shell

Rapportage en monitoring

Om op hoofdlijnen te zien op de replicatie plaats vindt, gebruik ik het volgende commando die de grootte van het .edb-bestand geeft:

Get-PublicFolderDatabase | Select Server, Name, @{Name="Size (GB)";Expression={$objitem = (Get-PublicFolderDatabase $_.Identity); $path = "`\`\" + $objitem.server + "`\" + $objItem.EdbFilePath.DriveName.Remove(1).ToString() + "$"+ $objItem.EdbFilePath.PathName.Remove(0,2); $size = ((Get-ChildItem $path).length)/1048576KB; [math]::round($size, 2)}}, @{Name="Size (MB)";Expression={$objitem = (Get-PublicFolderDatabase $_.Identity); $path = "`\`\" + $objitem.server + "`\" + $objItem.EdbFilePath.DriveName.Remove(1).ToString() + "$"+ $objItem.EdbFilePath.PathName.Remove(0,2); $size = ((Get-ChildItem $path).length)/1024KB; [math]::round($size, 2)}}

Deze one-liner ziet er misschien complexer uit dan hij is, dat komt omdat we het UNC pad moeten samenstellen om de grootte van het bestand te kunnen meten. Een andere stukje code is om de grootte om te rekenen naar GB en MB.

Door dit commando af en toe te herhalen zie je al snel dat het aantal GB's van de nieuwe databases toeneemt. Dit is natuurlijk niet voldoende om een goed beeld van de status te krijgen. Dus na enige tijd heb ik het Exchange 2010 Public Folder Replication Report van Mike Walker gebruikt.

Dit script gebruikt Get-PublicFolder en Get-PublicFolderSatistics om informatie over de public folders te vergaren. Omdat dit zeer lang kan duren, al snel enkele uren bij een paar duizend folders, beperkt ik het rapport tot een specifieke top-level folder:

.\Get-PublicFolderReplicationReport.ps1 -FolderPath "\MyFolder" -Recurse -ComputerName @("OldServer1", "OldServer2", "NewServer1", "NewServer2") -AsHTML -Filename report.html

Het resultaat is een zeer bruikbaar rapport in HTML-vorm.

Troubleshooting

Op basis van de bestandsgrootte was al duidelijk dat één van de nieuwe databases niet volledig gevuld werd en het HTML-rapport bevestigt dat. Om uit te vinden of er een probleem is heb ik het logging level voor een aantal relevante bronnen op de bron- en doelserver aangepast van Lowest naar High:

Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Incoming Messages" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Outgoing Messages" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication NDRs" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Backfill" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Errors" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication General" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Incoming Messages" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Outgoing Messages" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication NDRs" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Backfill" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Errors" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication General" -level high

Na enige tijd verschijnen er in het Application eventlog allerlei meldingen van source MSExchangeIS Public Store. Op zich zou ik die met PowerShell kunnen analyseren (Get-EventLog) maar voor een snel overzicht heb ik de Event Viewer gemaakt en een filter op source MSExchangeIS Public Store gezet.

image

De grote hoeveelheid errors bleken vals alarm te zijn, deze waren onschuldig en geen indicatie voor een daadwerkelijk probleem.

Om eventuele fouten te repliceren heb ik de replicatie voor een (op de nieuwe server niet gevulde) folder handmatig gestart:

Update-PublicFolder "MyFolder\SubFolder" -Server OldServer1

Op dit moment zie je direct de bijbehorende replicatie-events verschijnen op de bron- en doelserver. Vervolgende de statistieken voor deze folder opgevraagd op de oude en nieuwe server:

Get-PublicFolderStatistics "MyFolder\SubFolder" -Server OldServer1
Get-PublicFolderStatistics "MyFolder\SubFolder" -Server NewServer1

Na een paar minuten gaf de folder op de nieuwe server het zelfde aantal items als de oude. Daarom ook de rest van de folders nogmaals laten updaten:

Get-PublicFolder "MyFolder\SubFolder" -Recurse -ResultSize Unlimited | Update-PublicFolder -Server OldServer1

Daarna het Public Folder Replication Report nogmaals uitgevoerd en uitsluitend groene vlakjes gezien.

Tips

Met name bij het werken met grote hoeveelheden folders duren eenvoudige taken als het opvragen van folders of statistieken zeer lang. Plan dus vooruit en voorkom dat je langlopende taken opnieuw moet uitvoeren. Sla het resultaat van een query op in een CSV-bestand of variabele.

Deel de hoeveelheid data op in behapbare blokken, bijvoorbeeld een toplevelfolder met onderliggende mappen die voldoende items bevatten maar pakweg een paar GB groot zijn. Selecteer hiervoor desnoods een dieper gelegen folderstructuur. Besteed aandacht aan het verloop en zorg dat je goed inzicht hebt in het verloop of eventuele problemen. Los die eerst op en ga dan verder met de rest van de data.

Dit artikel heeft betrekking op Exchange 2010 maar is ook bruikbaar voor Exchange 2007. Om Public Folder replicatie goed te begrijpen moeten we terugvallen op documentatie voor Exchange 2003, afgezien van de gebruikte tools is er in Exchange 2007 en 2010 namelijk weinig veranderd. Een goed stuk documentatie is: Controlling Exchange Server 2003 Public Folder Replication

Exchange 2013 EAC werkt niet goed in Chrome 37

Hoewel één van de ondersteunde browsers, valt mij op dat Chrome versie 37.xxx problemen heeft met een paar onderdelen van het ECP van mijn Exchange 2013 CU6 servers. Zo is het bijvoorbeeld niet mogelijk om een smarthost toe te voegen aan een Send Connector:

image

Na een druk op de + gebeurt er niets. In IE11 en voorheen ook in Chrome verschijnt een nieuwe pop-up. Hetzelfde probleem treed ook op bij andere schermen waar je na een klik op + (Add) of de potlood (Edit) een nieuwe pop-up verwacht. Dat maakt de huidige versie van Chrome op dit moment minder geschikt om Exchange 2013 mee te beheren.

Web browsers supported for use with the premium version of Outlook Web App or Outlook Web Access

woensdag 10 september 2014

En daar is het derde issue met Exchange 2013 CU6...

Ik krijg nog wel eens het verwijt dat ik te kritisch ben en ook de positieve kant van de zaak moet belichten in mijn artikeltjes. Daar ga ik eens even goed over nadenken en zodra ik het ontdekt heb dan laat ik het direct weten. Maar nu kan ik niet anders dan diep zuchten en vertellen dat een derde serieus issue is opgedoken in Exchange 2013 CU6.

You cannot route ActiveSync traffic to Exchange 2007 mailboxes after you upgrade to Exchange 2013 CU6

Deze komt dus naast de al bekende issues:

En laat ik voor de volledigheid ook verwijzen naar de fix voor de fix in dat laatste artikel: Exchange2013-KB2997355-FixIt-v2 (Michel de Rooij)

Het issue waar het ditmaal om gaat is dat Exchange 2013 CAS een ActiveSync verzoek voor een gebruiker op Exchange 2007 niet correct kan authentiseren, laat staan verder verwerken.

Even een reminder, je weet waarschijnlijk dat Exchange 2013 CAS alle verzoeken voor mailboxen op Exchange 20007, 2010 ofwel Exchange 2013 servers in een andere site 'proxied' naar een andere CAS server. Een uitzondering is EAS voor Exchange 2007 mailboxen, deze wordt geproxied naar Exchange 2013 Mailbox die het verzoek vervolgens proxied naar Exchange 2007 CAS. Zie Client Connectivity in an Exchange 2013 Coexistence Environment

image

Bij eerdere issues traden er al problemen op met de EAS Application Pool op de 2013 Mailbox server wanneer hij een verzoek wil proxien naar 2007 CAS. Bij dit meest recente issue komt het probleem dus al voor op Exchange 2013 CAS.

Er is inmiddels een hotfix beschikbaar met de naam Exchange2013-KB2997209_2997847-x64-en.msp. Zoals de naam al verklapt verhelpt deze update beide Exchange 2007 coexistence issues.

Windows Phone 8.1 en het geheim van de verdwenen komma

De meeste gebruikers met een geschikte telefoon hebben inmiddels de Windows Phone 8.1 update gekregen. Die zit bomvol kleine en grote verbeteringen maar bracht ook een nadeel met zich mee: op het toetsenbord staat naast de punt geen komma meer. Het is maar een kleinigheid maar iedere keer wisselen tussen het numerieke en normale deel van het toetsenbord is erg onhandig om alleen een komma te kunnen gebruiken.

wp_ss_20140910_0001

Gelukkig kunnen we die weer terugzetten. Ga hiervoor naar Instellingen, Toetsenbord, Geavanceerd en zet een vinkje voor 'Een kommatoets weergeven indien beschikbaar'.

wp_ss_20140910_0002

En viola, hier is de komma weer terug:

wp_ss_20140910_0004

dinsdag 9 september 2014

Office 365 ProPlus nu ook op Terminal Server/RDS hosts!

Office 356 ProPlus is de versie van de welbekende Office-suite die je af kunt nemen als onderdeel van een Office 365 abonnement. Eens opgestart verschillen de losse applicaties niet van de versies die je kent uit Office Professional Plus 2013 maar onder de motorkap zijn er wel verschillen. Zo wordt Office aangeboden op basis van Click-to-Run (C2R), dit is een applicatievirtualisatietechnologie die we al langer kennen als App-V. Een ander verschil is het mechanisme waarmee de software geactiveerd kan worden, dit is bij Office 365 ProPlus vergelijkbaar met zoals dit in de Home abonnementen al langer gebeurt. De gebruiker krijgt de vraag om credentials in te geven en hiermee kan worden gecontroleerd of er een geldige Office 365 ProPlus licentie aan deze gebruiker toegewezen is.

Screen shot of the Office software page in the Office 365 portal

Dit kleine technologische verschil had tot voor kort wel tot gevolg dat je deze versie niet kon installeren danwel activeren op een Remote Desktop Services (RDS) host ofwel een Terminal Server. Voor klanten met een Volume License Agreement zoals EA, Select of Open was er in 2013 al een mogelijkheid om de Office 365 ProPlus licentie te laten gelden voor een Volume Activation versie van Office 2013. Maar de regels hiervoor zijn al even complex als de daadwerkelijke uitvoering.

Daarom is het goed om te weten dat je Office 365 ProPlus nu ook ook op een RDS host mag installeren. Dit is mogelijk gemaakt door een nieuwe feature: shared computer activation. Met deze feature kan een beheerder Office 365 ProPlus installeren op een computer die door meerdere personen gebruikt wordt, zoals bij RDS. Nu kan per ingelogde gebruiker vastgesteld worden of deze een licentie heeft of niet.

Zie voor meer informatie en stappen om dit uit te voeren: Overview of shared computer activation for Office 365 ProPlus Al met al zet Microsoft met deze feature een belangrijke stap om Office 365 te presenteren als acceptabel alternatief voor de grootzakelijke markt.

Meer weten van dit soort eigenaardigheden? Neem dan voor gebruik de bijsluiter door: Office Applications Service Description

woensdag 3 september 2014

Controleer je Office 365 MX-records met PowerShell

Als gebruiker van Office 365 dien je een aantal DNS-records te configureren om er zeker van te zijn dat e.e.a. goed werkt. Voor Exchange Online is dit bijvoorbeeld een CNAME voor autodiscover die naar autodiscover.outlook.com verwijst. Informatie over de benodigde records is te vinden in de Office 365 Portal wanneer in de Domains sectio op Manage DNS klikt. Of via deze url: https://portal.office.com/admin/default.aspx#@/Domains/ConfigureDomainWizard.aspx?Scenario=EDomainsSetup&domainName=imara-ict.nl (vervang de domeinnaam aan het eind van de url).

image

In de afgelopen jaren zijn deze records verschillende keren aangepast of aangevuld. Zo werd als MX-record voorheen een algemeen record gebruik zoals bijvoorbeeld mail.global.frontbridge.com of mail.messaging.microsoft.com. Tegenwoordig gebruiken we voor elk domein een specifiek record, op dit moment zijn de twee volgende geldig:

  • contoso-com.mail.eo.outlook.com
  • contoso-com.mail.protection.outlook.com

In de Office 365 Portal wordt momenteel die laatste gebruikt: contoso-com.mail.protection.outlook.com.

Om te controleren welke MX-records jouw organisatie ingesteld heeft staan kun je in Exchange Online PowerShell het Get-MxRecordReport cmdlet gebruiken. Deze geeft voor het domein de volgende informatie:

  • Is het een Accepted Domain?
  • Bestaat er een MX-record?
  • Wat is het MX-record met de hoogste prioriteit (laagste waarde voor prioriteit)?
  • Wat is het bijbehorende IP-adres?
  • Wijst het record naar Exchange Online (Exchange Online Protection EOP) via de mail.protection.outlook.com namespace?

Het cmdlet geeft output voor elke IP-adres wat gevonden wordt voor de betreffende hostnaam. Je kunt het cmdlet uitvoeren voor elk domein, maar het ligt voor de hand om dit alleen voor de domeinen te doen die je daadwerkelijk als accepted domain hebt opgevoerd:

Get-AcceptedDomain | % { Get-MxRecordReport -Domain $_.DomainName } | ft Domain,PointsToService,HighestPriorityMailhost,HighestPriorityMailhostIpAddress -AutoSize

image

Opvallend

Opvallend is dat PointsToService alleen True geeft als één van de twee namespaces voor MX-records wordt gebruikt. Bij de andere optie, die ook gewoon geldig is, krijgen we False terug.

Verder zou Microsoft er goed aan doen om de informatie over de vereiste DNS-records beschikbaar te maken via PowerShell of desnoods een API. De informatie opzoeken in de Portal werkt prima voor incidenteel gebruik maar in grootschalige implementaties zou je deze informatie geautomatiseerd willen benaderen. Gezien het tempo waarin de verbeteringen in Office 365 doorgevoerd worden sluit ik niet uit dat deze functionaliteit nog eens gaat verschijnen.