Vandaag tijdens het troubleshooten bij een klant liep ik tegen een probleem op wat ik de laatste tijd ook wel vaker op de diverse fora tegen kom, OWA laat een leeg scherm zien i.p.v. het inlogscherm. Maar waardoor wordt dit probleem nu door veroorzaakt? Er zijn hiervoor diverse oorzaken:

• niet alle benodigde Windows componenten zijn geïnstalleerd
• er zijn instellingen middels IIS aangepast waardoor OWA niet meer werkt

Benodigde Windows componenten ontbreken

De eerste oorzaak is eigenlijk best vreemd omdat je zou verwachten dat de installatie controleert of alle componenten geïnstalleerd zijn voordat begonnen wordt met de daadwerkelijke installatie van Exchange.

Wanneer bijvoorbeeld de static content niet is geïnstalleerd kan dit voor dit issue zorgen. Om het e.e.a. te vergemakkelijken kun je gebruik maken van onderstaande script wat alle benodigde componenten op een Windows 2008 server zal installeren welke als CAS server gaat fungeren:

ServerManagerCmd -i Powershell
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression

Indien je van plan bent om Outlook Anywhere te gaan gebruiken vergeet dan niet de RPC over HTTP feature te installeren:

ServerManagerCmd -i RPC-over-HTTP-proxy

Wanneer bovenstaande componenten eenmaal zijn geïnstalleerd kun je beginnen met de installatie van Exchange 2007.

OWA virtual directory configuratie is corrupt

De tweede oorzaak kan zijn dat er instellingen middels IIS zijn aangepast. Eén van de grootste fouten die je kunt maken is dit doen. Op e.o.a. manier vindt Exchange dit toch niet echt leuk, gebruik daarom de Exchange Management Shell of Exchange Management Console om wijzigingen door te voeren.

Mocht je toch dingen hebben gewijzigd middels IIS en werkt OWA hierna niet meer dan is er maar één oplossing. Verwijder de OWA virtual directory en maak heb opnieuw aan. Dit kan eenvoudig gedaan worden d.m.v. de commando’s remove-owavirtualdirectory en new-owavirtualdirectory te gebruiken.

Als eerste stap verwijderen we de oude OWA directory:

remove-owavirtualdirectory “owa (Default Web Site)”

Dit zorgt ervoor dat de OWA virtual directory wordt verwijderd in IIS:

Vervolgens maken we de nieuwe OWA directory:

new-owavirtualdirectory -OwaVersion “Exchange2007″ -Name “owa (Default Web Site)”

Dit zorgt ervoor dat de OWA virtual directory opnieuw wordt aangemaakt en als je geluk hebt werkt OWA nu weer. Dit zijn slechts 2 mogelijke oorzaken van het probleem, mocht je er meer tegenkomen laat het me dan weten zodat ik deze aan het artikel toe kan voegen johan (a)  johanveldhuis.nl

Gepost in Exchange 2007 ~ Geen Reactie

Volgens de Technet documentatie zou je gewoon Exchange 2010 naast Exchange 2007 moeten kunnen draaien. Laatst kreeg ik een vraag van een klant die hiermee problemen had. De huidige Exchange 2007 omgeving was up-to-date en Service Pack 3 was dus geïnstalleerd. Tijdens het uitbreiden van het schema middels het setup.com /ps commando was de volgende foutmelding te zien:

Het schema versie van Exchange 2007 SP3 is dus hoger als die van de Exchange 2010 setup. Dit maakt het dus niet mogelijk om Exchange 2010 te installeren.

Wanneer Exchange 2007 SP3 dus is geïnstalleerd zul je moeten wachten tot er een service pack uitkomt waarin het schema wordt uitgebreid. Aangezien waarschijnlijk veel mensen Exchange 2007 SP3 installeren zal dit vermoedelijk in SP1 van Exchange 2010 verwerkt zijn.

Onderstaand een overzicht van Exchange versies met hierbij de versie van het schema wat gebruikt wordt:

Exchange	Schema
Exchange 2000 RTM	4397
Exchange 2000 SP3	4397
Exchange 2003 RTM	6870
Exchange 2003 SP3	6936
Exchange 2007 RTM	10628
Exchange 2007 SP3	14625
Exchange 2010	14622

Mocht je willen weten hoe je kunt achterhalen wat de huidige versie van je AD schema is kijk dan eens op onderstaande site:

open

Gepost in Exchange 2010 ~ 7 Reacties

Eén van de nieuwe features in Exchange 2007 Service Pack 3 is de mogelijkheid om een gebruiker zijn/haar wachtwoord te laten wijzigen voordat hij is ingelogd. Voor service pack 3 was het niet mogelijk om in te loggen via OWA zodra je wachtwoord was verlopen. Met deze nieuwe mogelijkheid word je omgeleid naar een aparte pagina waar je vervolgens je wachtwoord kunt wijzigen.

Maar hoe werkt dit principe nu precies? In de directory van OWA, te vinden onder Exchange\ClientAccess\Owa vind je de directory auth. Deze directory bevat enkele bestanden welke nodig zijn om een gebruiker in te laten loggen en uit te laten loggen. Maar naast deze bestanden staan er ook twee nieuwe bestanden expiredpassword.aspx en exppw.dll.

Voordat je gebruik kunt maken van de nieuwe functionaliteit zal je een aanpassing moeten maken in het register van de CAS server. Ga hiervoor naar onderstaande locatie in het register:

HLKM\SYSTEM\CurrentControlSet\Services\MSExchange OWA

Maak vervolgens een DWORD aan met de naam ChangeExpiredPasswordEnabled en geef de nieuwe key de waarde 1. Eenmaal toegevoegd zal dit er als volgt uitzien:

Wanneer tijdens het inloggen (logon.aspx) wordt gedetecteerd dat het wachtwoord is verlopen en de gebruiker het direct moet wijzigen zal de gebruiker omgeleid worden naar het bestand expiredpassword.aspx.

Voordat de gebruiker zijn/haar wachtwoord kan wijzigen dient hij als extra controle het oude wachtwoord op te geven. Eenmaal aangepast wordt de gebruiker direct naar zijn/haar mailbox omgeleid.

Gepost in Exchange 2007 ~ Geen Reactie

Vandaag weer een leuk probleem tegengekomen bij een klant die probeerde een Exchange test omgeving op te zetten. Het vereist echter wel even een korte introductie.
Stel je hebt een AD forest met daarin een child domain waar je vervolgens Exchange in wil installeren.
Je zal dan eerst de voorbereidingen treffen in het forest door het schema updaten en vervolgens het forest uit te breiden. Als laatste stap kun je wanneer de replicatie heeft plaatsgevonden het child domain voorbereiden.

Normaliter zul je hier vaak dezelfde installatie cd voor gebruiken, maar in Exchange 2007 kan dit weleens anders zijn. Dit aangezien er van Exchange 2007 nog een 32-bit versie was die voor test doeleinden gebruikt kon worden en voor schema/forest preps op een 32-bit DC.

Je voelt hem misschien al aankomen? Alles was netjes volgens de procedure gedaan en toch kwamen er diverse foutmeldingen naar voren waaronder onderstaande:

[2/7/2010 11:30:46 PM] [0] Setup has chosen the local domain controller dc.ota.company.corp for initial queries
[2/7/2010 11:30:46 PM] [0] PrepareAD has either not been run or has not replicated to the domain controller used by Setup. Setup will attempt to use the Schema Master domain controller dc.company.corp
[2/7/2010 11:30:46 PM] [0] The schema master domain controller is available

Dus maar eens gecontroleerd of de connectie naar de betreffende servers goed verliep en dit was geen probleem. Omdat het om een test omgeving ging als uiterste nood maar de schema master verplaatst, dit hielp echter weinig en veroorzaakte weer een andere melding:

[2/8/2010 3:32:34 PM] [1] [ERROR] PrepareDomain for domain ota has partially completed. Because of your Active Directory site configuration, you must wait for forest-wide replication to occur, and then run PrepareDomain for ota again.
[2/8/2010 3:32:34 PM] [1] [ERROR] Active Directory operation failed on dc.ota.company.corp. This error is not retriable. Additional information: The specified group type is invalid.
Active directory response: 00002141: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0

Echter het wachten had weinig zin en dus toch maar weer de originele configuratie teruggebouwd. Toen eens Exchange via de GUI opgestart en toen zag ik het meteen. De bestanden die gebruikt werden waren van Exchange 2007 RTM en niet van Exchange 2007 SP1. Toen we die bestanden gebruikte werkte het natuurlijk meteen

Al met al weer een leuke puzzel.

Gepost in Exchange 2007 ~ Geen Reactie

Microsoft heeft rollup 2 voor Exchange 2007 SP2 vrij gegeven, deze rollup bevat o.a. de volgende fixes:

• CAS server wordt trager wanneer een gebruiker mappen opent met veel inhoud
• Afspraken worden weergeven als een afspraak voor een hele dag terwijl dit niet het geval is wanneer deze gesynchroniseerd worden middels een mobiel apparaat
• de log en database groeien enorm
• mails richting remote domains blijven in de queue hangen

Dit zijn slechts enkele fixes in Rollup 2 voor een volledig overzicht kun je terecht op onderstaande site.

open

Gepost in Exchange 2007 ~ Geen Reactie

Zo weer eens tijd voor een tutorial, dit keer over de autodiscover functionaliteit in een multiforest omgeving. Normaliter kan autodiscover aardig wat kopzorgen bezorgen laat staan in een multiforest omgeving. In deze tutorial leg ik uit hoe je dit kunt configureren en vervolgens kunt testen.

open

Gepost in Tutorials ~ 2 Reacties

Autodiscover, echt een superhandige functionaliteit van Exchange maar het kan je ook veel kopzorgen bezorgen. Wanneer je het gaat implementeren komen hier in een multiforest nog wat extra dingen bij kijken. In deze tutorial beschrijf ik de stappen die hiervoor nodig zijn en laat ik ook zien wat er precies fout gaat als je het niet goed configureert.

Onderstaand een schematisch overzicht van de omgeving:

In deze omgeving zijn de volgende forests aangemaakt:

• demo.local, het user forest. Hier bevinden zich alle gebruikersaccounts in. Dit forest bevat alleen een domaincontroller.
• exchange.local, een van de Exchange resource forests. Dit forest bevat een Exchange server met zowel de HUB, CAS als mailbox role, daarnaast is deze server een domaincontroller.
• company.local, een van de Exchange resource forests. Dit forest bevat een Exchange server met zowel de HUB, CAS als mailbox role, daarnaast is deze server een domaincontroller.

Wat willen we nu gaan bereiken in deze omgeving. De gebruikersaccounts worden aangemaakt in het demo.local forest. De gebruikers zullen in aparte OU’s geplaatst worden zodat er een onderscheid gemaakt kan worden tussen de gebruikers met een mailbox in het exchange.local forest en het company.local forest. Vervolgens zullen in de resource forests linked mailboxes gemaakt worden. Dit forest zal wel gebruikersaccounts bevatten maar deze accounts zullen uitgeschakeld zijn. De gebruikers zullen dus inloggen op het demo.local domein en vanuit daar Outlook dienen te configureren m.b.v. autodiscover.

De installatiestappen van zowel de domaincontrollers als de Exchange servers slaan we even over, en gaan er dus vanuit dat we 3 forests hebben met daarin de eerder genoemde servers met bijbehorende software.

Als een van de eerste dingen moeten we ervoor zorgen dat er een trust bestaat tussen de forests. Voordat we de trust op kunnen zetten moeten we ervoor zorgen dat DNS resolving goed werkt. Dit kan door een forwarder in te stellen op de DNS server in het resource forest naar de DNS server in het user forest en andersom.

Vervolgens kan de trust aangemaakt worden, dit kan via het commando netdom:

Netdom trust trusted_domain_name /domain: trusting_domain_name /verify

Of via Active Directory Domains en Trusts de trust, dit kan middels een wizard:

Geef de naam van het user forest op.

<

Geef in de volgende stap aan dat het gaat om een forest trust en klik op next.

Vervolgens stellen we in dat dit om een outgoing trust gaat, dit omdat gebruikers uit het user forest zich alleen hoeven te kunnen authenticeren in het resource forest en niet andersom.

Daarna kunnen we aangeven dat de trust in beide forests wordt aangemaakt, als je in beide forests een account hebt met voldoende rechten is dit natuurlijk het makkelijkst.

Geef de account op die gebruikt gaat worden voor authenticatie in het andere domein en druk op next.

Een van de laatste stappen is het maken van de keuzes tussen een forest-wide of selective authenticatie. Hiermee kun je instellen of dat je direct het hele forest toegang geeft tot het resource forest of dat je dit later per gebruiker configureert.

Na de korte samenvatting dien je op next te drukken om de trust aan te maken, wanneer dit succesvol wordt afgerond zul je het volgende scherm te zien krijgen.

Vervolgens kun je nog een extra check uitvoeren indien je dit wenst.

Dit zal vervolgens een overzicht geven van de test resultaten.

Voordat we de volgende stappen uit kunnen voeren moeten we de gebruiker hebben aangemaakt in user forest. Dit kan via Active Directory Users & Computers en kan gewoon een standaard gebruiker zijn. Wanneer de gebruiker is aangemaakt kunnen we de linked mailbox aan gaan maken, open hiervoor de Exchange Management Console of de Exchange Management Shell.

Wanneer je kiest voor de EMS dien je onderstaande command uit te voeren:

New-Mailbox -Database “Mailbox Database” -Name “Demo User” -LinkedDomainController “dc.demo.local” -LinkedMasterAccount demo\demouser -OrganizationalUnit Exchange\Users -UserPrincipalName demouser@exchange.local -LinkedCredential:(Get-Credential demo\administrator)

Open vervolgens recipient configuration en selecteer het mailbox item.

Klik vervolgens met de rechtermuisknop op mailbox en kies voor de optie new mailbox.

Er zal nu een wizard geopend worden.

Kies vervolgensde optie linked mailbox en klik op next.

In het volgende scherm kun je kiezen om een bestaande gebruiker te selecteren of een nieuwe, let op het gaat hier om een gebruiker in het resource forest dus niet in het user forest.

Vul de benodigde velden in en druk vervolgens op next.

Selecteer vervolgens de database waar de mailbox in aangemaakt moet worden en de eventuele activesync en managed folder policy die op de gebruiker toegepast moet worden.

In dit scherm selecteren we de account waar de mailbox aangekoppeld moet worden, dit is een gebruikersaccount in het user forest. Je kun de gebruiker eenvoudig selecteren door op de knop browse te drukken. Wanneer de correcte gebruiker is geselecteerd kun je op next drukken.

Hierna zal een korte samenvatting worden weergeven en wanneer wederom op next gedrukt wordt zullen zowel de gebruiker als de mailbox aangemaakt worden.

Zoals bovenstaand te zien is is de gebruiker succesvol aangemaakt.

Wanneer de mailbox is aangemaakt zijn we in principe klaar om het e.e.a. te testen, deze test zal niet slagen omdat in het user forest niks bekend is van de autodiscover functionaliteit in het resource domein.

We starten Outlook op en krijgen het volgende scherm te zien.

We vullen hier netjes de gegevens in van de gebruiker en drukken op next om door te gaan.

Na enkele seconden zal Outlook met de melding komen dat er geen beveiligde verbinding opgezet kan worden naar de server. Outlook biedt de optie om dan een onbeveiligde verbinding op te zetten, klik op next om dit te proberen.

Ook dit zal mislukken en Outlook zal vragen om de gegevens te controleren. We weten in dit geval 100% zeker dat deze correct zijn. Maar hoe komt dit nu ?

Wanneer we naar de werking van autodiscover vanaf het LAN gaan kijken zien we wat er gebeurd wanneer de client een autodiscover doet:

Zoals te zien is wordt er een query gedaan naar het Service Connection Point (SCP), dit object is te vinden in de configuratie partitie van de Active Directory. In het user forest zal deze echter niet bestaan.

Om dit zeker te weten kunnen we adsiedit uitvoeren op een domain controller in het user forest. Vervolgens openen we de configuration en gaan naar:

CN=Services, CN=Configuration, CN=domain, CN=local

Om dit aan te maken dienen we in het resource forest het volgende commando uit te voeren:

Export-AutoDiscoverConfig -DomainController DomainControllerName -TargetForestDomainController TargetForestDomainControllerName -MultipleExchangeDeployments $true

Opzich spreken denk ik alle parameters voor zich, misschien vraagt de laatste alleen om een wat andere uitleg. Wanneer deze parameter de waarde TRUE heeft wordt hiermee aangegeven dat er meerdere Exchange forests bestaan. Opzich niet zo heel spannend zul je denken maar dat is het opzich wel. Deze parameter zorgt er namelijk op dat moment ook voor dat alle accepted domains welke zijn ingesteld in de betreffende Exchange omgeving mee worden geexporteerd. Dit heeft dus tot gevolg dan als er een accepted domain wordt toegevoegd het commando weer opnieuw gedraaid moet worden.

Wanneer je na het draaien van het commando nogmaals zult kijken op de domain controller van het user forest zul je zien dat de autodiscover service is toegevoegd.

Per Exchange forest zal hier dus een map verschijnen, in ons geval dus zowel voor exchange.local als voor company.local.

Wanneer je nu de eigenschappen van de map opvraagt en naar de waarde van keywords en serviceBindingInformation kijkt zul je zien dat hier verwijzingen staan naar het resource forest. Het keyword attribuut bevat de Active Directory site waar de CAS server lid van is. Het serviceBindingInformation attribuut bevat de FQDN van de CAS server in het volgende formaat https://ex.exchange.local/autodiscover/autodiscover.xml. Wanneer de replicatie heeft plaatsgevonden in het user forest is het tijd om het nogmaals te proberen, we starten daarom Outlook weer op.

Voeren nogmaals de gegevens in en drukken op next

Zoals bovenstaand te zien is is de automatische configuratie nu goed gelukt en wanneer we via Outlook de connectie testen is hier ook te zien dat de connectie nu succesvol is opgezet.

Interessante links:

MsExchange Team: Configuration Tips and common troubleshooting steps for multiple forest deployment of Autodiscover service open
Technet: White Paper: Exchange 2007 Autodiscover Service open
Technet: How to create a linked mailbox open

Gepost in ~ Geen Reactie

Vandaag weer een nieuwe Exchange omgeving in de lucht gebracht. Ditmaal in een greenfield, een omgeving die helemaal separaat van de oude omgeving wordt gebouwd. Aangezien een groot gedeelte van de serveromgeving direct wordt gevirtualiseerd was ook Exchange aan de beurt. De keuze was in dit geval gevallen op Citrix XenServer, geen probleem aangezien die ook op de lijst bij Microsoft voor komt.

Dus gewoon lekker aan het installeren geslagen nadat het design was goedgekeurd. Omdat er ondertussen ook nog wat kleine dingen gedaan moesten worden op andere servers had ik Xencenter geopend zodat ik gelijk bij alle servers kon. Opzich geen probleem z0u je zeggen, totdat Exchange met de uitbreiding van de AD begon, daar liep ik na enige minuten tegen de melding you do not have permissions to read the security descriptor on cn=deleted  objects,cn=configuration,dc=ishw,dc=local. Zeer vreemd want de account had voldoende rechten en replicatie tussen de dc’s verliep netjes. Na wat zoekwerk had ik een mogelijk aantal oorzaken gevonden:

- schrijfletter van de cd/dvd-rom wijzigen, deze optie viel af aangezien de installatie op een fileshare stond
- rechten corrigeren met ADAM, aangezien ik deze optie een beetje te rigoereus vond besloot ik deze ook maar over te slaan
- installeren via de console, is echter een beetje lastig achter een vm, dus dan maar een RCP met de /console of /admin optie

De laatste optie bleek de oplossing te zijn, blijkbaar maakt XenCenter dus ook een RDP connectie alleen zonder de /console of /admin optie. Mocht je dus in de toekomst Exchange installeren in een XenServer omgeving let hier dan even op.

Onderstaand nog wat interessante artikelen:

Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments open
Security descriptor error during Exchange Server 2007 schema extension open
Technet Forum: Exchange 2007 Install Error : Read Security Descriptor open

Gepost in Exchange 2007 ~ Geen Reactie

Vanaf Exchange 2010 zal Microsoft geen gebruik meer maken van single instance storage. Maar waar zorgt de single instance storage nu eigenlijk voor en wat zijn de voor/nadelen ervan?

Single instance storage is al aanwezig sinds Exchange 4.0 en is tot Exchange 2007 naast wat kleine aanpassingen niet gewijzigd. Single instance storage zorgt ervoor dat als een mail naar bijvoorbeeld 50 gebruikers is gestuurd dat de mail slechts 1 maal per mailstore wordt opgeslagen. Voor de overige mailboxen worden pointers aangemaakt naar de betreffende mail, dit geldt zowel voor de mail als voor het attachment.  Vanaf Exchange 2007 heeft Microsoft dit echter aangepast en wordt alleen het attachment via single instance storage opgeslagen. Dit geldt echter niet als een mailbox wordt gemigreerd van Exchange 2000/2003 naar Exchange 2007. In dat geval worden zowel het bericht als het attachment nog via single instance storage opgeslagen als aan een van onderstaande voorwaarden wordt voldaan:

• de mailboxen die worden verplaatst moeten bij elkaar blijven in een database
• er vindt een transistie plaats i.p.v. een migratie naar Exchange 2007

Je zal je natuurlijk afvragen waarom Microsoft in Exchange 2010 helemaal geen gebruik meer maakt van SIS. Eigenlijk is de reden hiervan redelijk te voorspellen, storage is namelijk vele malen goedkoper geworden dan dat het vroeger was. Een van de voordelen die met SIS bereikt kon worden is dat er minder disk-capaciteit nodig was. Een van de nadelen is dat het aantal IOPS dat benodigd is wel meer is dan zonder SIS. Tegenwoordig ligt de focus vaak op het reduceren van IOPS dat benodigd is i.p.v. de disk-capaciteit die hiervoor nodig is.

Onderstaand wat handige links:

Technet: understanding single instance storage open
MsExchange Team: single instance storage in Exchange 2007 open
Harold Wong’s Blog site: Exchange 2010 archiving and retention open

Gepost in Exchange ~ Geen Reactie

Even een simpel Powershellscript, onderstaande script maakt het mogelijk om een vergaderzaal aan te maken en direct extra rechten hier aan toe te voegen voor in dit geval de administrator:

Param(
[string] $room
)
New-Mailbox -database “MBX-srv\Mailbox Database” -Name $room -OrganizationalUnit “Conference Rooms” -DisplayName $room -UserPrincipalName $room@domain.local -Room
Add-adpermission $room -User domain\administrator -Extendedrights “Receive-As”

Uitvoeren als: new-room.ps1 “meetingroom1″

Het script gaat er vanuit dat de vergaderzalen geplaatst worden in een aangemaakte OU Conference Rooms.

Eerst wordt de naam uitgelezen die als naam wordt opgegeven tijdens het uitvoeren van het Powershell script. Hierna wordt de mailbox van het type room aangemaakt. Hierna worden er rechten toegevoegd middels het add-adpermission commando, in dit geval receive-as maar dit kan natuurlijk ook send-as zijn.

Onderstaand nog wat handige links naar de betreffende Technet artikelen over de commando’s

Technet add-adpermission open
Technet new-mailbox open

Gepost in Exchange 2007 ~ Geen Reactie