Nieuwe baan!

Vandaag neem ik afscheid van Imara ICT en kijk ik terug op een ontzettend leuke, leerzame en uitdagende tijd waarin ik samen met Peter Noorderijk mooie successen behaald heb. Als ik nu terugkijk naar de onderneming die we opgebouwd hebben kan ik alleen maar trots zijn. Toch heb ik er voor gekozen om 1 januari 2015 verder te gaan als onafhankelijk consultant onder de naam Mellema ICT B.V., hier kan ik me weer 100% focussen op consultancy op het gebied van Microsoft Messaging en Cloud Computing.

Voor de meeste van mijn relaties verandert er niet veel en blijf ik ook in 2015 beschikbaar voor opdrachten, zij het onder een nieuwe naam. Mijn mobiele nummer en postadres blijft gelijk, mijn nieuwe mail- en Lyncadres is jetze@mellema-ict.nl. Overige contactgegevens vind je op www.mellema-ict.nl waar binnenkort een mooie website verschijnt.

Verder wil ik Peter bedanken voor de mooie manier waarop we één en ander geregeld hebben en hem veel succes wensen met het voortzetten van Imara ICT. En natuurlijk wens ik iedereen een goed en succesvol 2015, zakelijk maar vooral privé!

UR8 voor Exchange 2010 SP3? Wacht nog maar even

Nadat Microsoft gisteren de nieuwe verzamelupdates voor Exchange 2007, 2010 en 2013 uitbracht is het altijd even spannend. Wie installeer ze als eerste, wie loopt tegen problemen aan?

Op dit moment melden twee afzonderlijke gebruikers op Tweakers.net dat zij een issue zien na installatie van RU8 op Exchange 2010 SP3. Het gaat hierbij om Outlook 2010, niet 2013 en alleen in online mode. Gebruikers zien Outlook vastslaan na het aanmaken van een nieuw item, bijvoorbeeld in de agenda.

In de event logs van de servers word een event gemeld die vergelijkbaar is met deze:

Watson report about to be sent for process id: xxxx, with parameters: E12, c-RTL-AMD64, 14.03.0224.001, M.E.RpcClientAccess.Service, M.E.RpcClientAccess.Handler, M.E.R.H.ViewCache.IsRowWithinUnreadCache, System.IndexOutOfRangeException, 8e38, 14.03.0224.001.
ErrorReportingEnabled: False

Een call is geopend bij Microsoft en ik ben aan het kijken of ik dit issue kan reproduceren. Totdat meer duidelijk is zou ik even wachten met de installatie van de laatst updates... Maar dat advies geef ik eigenlijk iedere keer.

Security-update beschikbaar voor Exchange 2007, 2010 en 2013

Microsoft heeft een fix uitgebracht voor Outlook Web App in alle ondersteunde versies van Exchange. Het gaat om vier verschillende issues, drie daarvan komen alleen in Exchange 2013 voor en de vierde ook in Exchange 2007 SP3 en 2010 SP3. In alle gevallen gaat het om beveiligingsproblemen die zijn aangemerkt als Important.

Zoals alle beveiligingsupdates worden ook deze aangeboden via Microsoft Update, maar wie dit voor wil zijn kan ze handmatig downloaden:

Exchange 2007 SP3

Exchange 2010 SP3

Exchange 2013 SP1

Exchange 2013 CU6

Versies die hier niet bij staan worden niet meer ondersteund of zijn niet kwetsbaar. Lees voor meer informatie het security bulletin MS14-075: Vulnerabilities in Microsoft Exchange Server Could Allow Elevation of Privilege (3009712)

Autodiscover testen met Outlook

Outlook die zijn eigen profiel configureert zonder dat de gebruiker hier iets aan hoeft te doen, en het werkt ook voor ActiveSync! Het kan sinds Exchange 2007 en Outlook 2007, maar Autodiscover heeft van het begin af voor verwarring gezorgd. In dit artikel ga ik niet in over de exacte werking maar laat ik een 'client-side' troubleshooting tool zien die ons zowel de werking van het proces laat zien, als de daadwerkelijke informatie die de client van de Autodiscover Service krijgt.

Je hebt nodig:

• Outlook 2007 of hoger
• Een Outlook profiel

Dat Outlook profiel mag een leeg profiel zijn of eentje met nepgegevens, bijvoorbeeld voor POP3 en SMTP.

Zoek het Outlook icoontje in de System Tray, klik er met de rechtermuisknop op terwijl je CRTL ingedrukt houdt. Kies nu Test E-mail AutoConfiguration:

Wanneer je als AD gebruiker op een AD member computer ingelogd bent leest Outlook het windowsEmailAddress attribuut uit en vult deze alvast in. In alle andere gevallen vul je je mailadres en wachtwoord in. Haal de vinkjes voor Guessmart weg.

Klik nu op Test, waarna Outlook een Autodiscover lookup gaat doen met de hierboven ingevulde gegevens. Afhankelijk van de configuratie kan dit even duren, het is dan ook interessant om tijdens het uitvoeren direct het tabblad Log in de gaten te houden, hier kunnen we de voortgang van het proces volgen:

In dit geval gaat het om een Office 365 mailbox waarbij het proces wat complexer is, maar het belangrijkste is dat de laatste regels aangeven dat het proces geslaagd is. Bij een ander resultaat betekent dit dat je de stappen doorleest en na gaat of ze overeenkomen met de wijze waarop je Autodiscover geconfigureerd hebt.

Dan terug naar het tabblad Results, deze geeft het ontvangen resultaat netjes weer maar bevat feitelijk dezelfde informatie als de ruwe XML die we op het derde tabblad kunnen zien.

Op deze plek controleren we de daadwerkelijk ontvangen informatie, grotendeels bepaald door wat we als InternalURL en ExternalURL waardes hebben geconfigureerd in Exchange.

Met dit handige hulpmiddel wordt het troubleshooten van Autodiscover een stuk eenvoudiger.

Apple iOS 8.x en issues met vergaderverzoeken

Het was een tijdje rustig op dit front maar in de nieuwste versie van de software voor Apple's iPhone en iPad zit een bug die vergaderverzoeken verminkt. Dit gebeurt wanneer de gebruiker eerst eigenschappen aanpast, zoals het veranderen van de Show As status, aanpassen van de Alert value of het toevoegen van een commentaar voor de organisator, en het verzoek pas daarna accepteert.

In deze gevallen kapt iOS de body van het bericht af na 500 karakters. Zo kan het gebeuren dat HTML of RTF berichten opeens als plain-text weer worden gegeven of dat de url in een invite voor een Lync meeting halverwege afgekapt wordt.

Workarounds:

• Accepteer het verzoek eerst, pas dan pas de eigenschappen aan
• Zet het syncen van de agenda uit
• Stap over op de OWA app voor iPhone/iPad

Meer informatie in het volgende KB-artikel: Known calendaring issues with iOS 8.x devices

Belangrijke security-update voor Exchange

Op 11 november brengt Microsoft een aantal Security Bulletins uit, dit keer gaat het om 16 gemiddelde tot ernstige beveiligingsproblemen waarvoor een fix gemaakt is. Ditmaal zit er ook een security update bij voor alle recente en ondersteunde versies van Exchange: 2007 SP3, 2010 SP3, 2013 SP1 en CU6.

Het issue is geclassificeerd als Important en lost een probleem op waarbij een aanvaller zich rechten zou kunnen verschaffen op een server. Het advies is om Important updates bij de eerstvolgende gelegenheid te installeren. Dan weet je het alvast...

Meer informatie hier: Microsoft Security Bulletin Advance Notification for November 2014

Wordt Exchange ondersteund in Azure, vCloud of AWS?

Nee.

Het Startmenu vervangen door Startscherm in Windows Server Technical Preview

Windows 10 is leuk, maar wij zijn natuurlijk veel meer geïnteresseerd in wat er op servergebied komen gaat. Eén van de dingen die als eerste opvalt is dat het startscherm vervangen is door een startmenu.

Gelukkig kun je dat eenvoudig herstellen. Klik met de rechtermuisknop de de taakbalk en kies Properties. Kies voor het tabblad Start Menu en haal het vinkje weg voor de optie Use the Start menu instead of the Start screen:

Om deze aanpassing door te voeren moet je uit- en weer inloggen.

Spamhaus RBL werkt niet met Google DNS

In mijn Exchange 2013 lab heb ik een Edge Transport server geconfigureerd om de Spamhaus Real-time Block List te gebruiken. Door een IP Block List Provider toe te voegen en de Connection Filtering agent in te schakelen test Exchange of de mailserver die een bericht wil afleveren niet op een RBL staat.

Helaas bleek dat bij mij niet te werken, dit werd bevestigd door een test met behulp van de Crynwr Spamhaus test. Raar, want het is een eenvoudige configuratie:

Add-IPBlockListProvider -Name Spamhaus -LookupDomain zen.spamhaus.org

De Connection Filtering transport agent staat standaard ingeschakeld, dat was het probleem dus ook niet. De volgende stap is het handmatig controleren of je een DNS query naar de servers van Spamhaus kunt doen. Dit kun je doen door een IP-adres te kiezen, bijvoorbeeld 127.0.0.2, en hiermee een query te construeren. Zet het IP-adres in omgekeerde volgorde en laat deze eindigen op .zen.spamhaus.org. In dit geval moeten we dus een DNS query doen voor 2.0.0.127.zen.spamhaus.org, het antwoord bevat een code die aangeeft of het IP wel of niet op de blocklist staat. En in dit geval zijn we niet geïnteresseerd in het antwoord maar willen we in eerste instantie controleren of de query überhaupt mogelijk is.

nslookup 2.0.0.127.zen.spamhaus.org

In dit voorbeeld gebruik ik een interne DNS-server waarvan ik de naam verborgen heb, maar in mijn lab mislukte deze test. De oorzaak bleek te liggen in de publieke Google DNS servers die ik als forwarder had geconfigureerd, dit zijn de populaire 8.8.8.8 en 8.8.4.4 adressen. Wanneer we dezelfde query uitvoeren tegen één van deze DNS-servers dan mislukt deze:

nslookup 2.0.0.127.zen.spamhaus.org 8.8.8.8

Bij nader onderzoek blijkt dat Spamhaus dit ook vermeldt in hun FAQ:

Check what DNS resolvers you are using: If you are using a free "open DNS resolver" service such as the Google Public DNS or large cloud/outsourced public DNS servers, such as Level3's or Verizon's, to resolve your DNSBL requests, in most cases you will receive a "not listed" (NXDOMAIN) reply from Spamhaus' public DNSBL servers. We recommend using your own DNS servers when doing DNSBL queries to Spamhaus.

In andere gevallen kan er natuurlijk een andere oorzaak zijn, maar deze troubelshooting methode kan een eerste stap zijn om te controleren of je de servers van Spamhaus kunt raadplegen.

Bron

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.

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:





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.