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

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

Laatste tijd komt het wel regelmatig voor dat je spam ontvangt welke lijkt te worden verzonden vanaf een account in je eigen domein. Wanneer je echter op verder onderzoek uitgaat blijkt dit niet zo te zijn. Maar waarom trapt Exchange hier dan toch elke keer weer in. Het antwoord vond ik op Exchangepedia blog. Elke mail vanaf internet wordt geaccepteerd namens de Anonymous User, haal je deze gebruiker weg van de receive connector dan zal er geen mail meer van internet binnen komen. Deze gebruiker heeft natuurlijk een aantal rechten nodig om dit wel te mogen, een van de rechten is Ms-Exch-Accept-Authoritative-Domain-Sender welke ervoor zorgt dat elke sessie welke verzonden wordt vanaf een domein wat geconfigureerd staat als authoritative domain niet gecontroleerd wordt.

Om dit te voorkomen dien je de rechten te verwijderen middels onderstaande command:

Get-ReceiveConnector “Internet” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

Let wel op dat wanneer je deze regel hebt verwijderd van de connector eventuele andere internet applicaties/apparatuur hier geen gebruik meer van kan maken. Voor deze applicaties/apparatuur dient dan een aparte receive connector aangemaakt te worden.

Gepost in Exchange 2007 ~ Geen Reactie

Ik weet het klinkt gek maar toch kan het, Chinese tekens in non-delivery reports. Na verder onderzoek viel ik van de ene verbazing in de andere, wanneer het betreffende mailtje werd uitgeprint was de tekst gewoon Nederlands.

Wanneer een zelfde mail werd gestuurd vanaf een Outlook 2003/2007 client was het probleem niet zichtbaar. Dus maar besloten om te gaan zoeken op internet en na wat zoeken kwam ik op het Technet forum terecht waar een vergelijken probleem werd gemeld.

Het probleem blijkt te worden veroorzaakt door een bugje in Outlook XP wat uiteraard niet meer gefixt gaat worden. Om even alles op een rijtje te zetten wanneer het probleem zich voordoet hieronder een kort overzicht:

• mail-client is Outlook XP
• komt alleen voor wanneer de NDR van het type HTML is
• wanneer de mail wordt uitgeprint is de tekst gewoon leesbaar

Om dit probleem op te lossen dien je de Hub server te vertellen dat alle NDR’s verzonden moeten worden als plain-text NDR’s, dit kan door het volgende Powershell commando uit te voeren:

Get-TransportServer | Set-TransportServer –InternalDsnSendHtml $False

Een andere oplossing is natuurlijk Outlook updaten naar 2003 of hoger aangezien het probleem zich hier niet in voordoet.

Gepost in Exchange 2007 ~ 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

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

Exchange 2010 RTM zal waarschijnlijk binnenkort wel uitkomen, daarom nog maar even een nieuwe tutorial voor Exchange 2007.

Dit keer over het installeren van een certificaat, dit bestaat uit diverse stappen:

• het aanmaken van een certificate request
• het genereren van een certificaat bij de CA server
• het installeren van het certificaat

Bovenstaande stappen worden stap voor stap beschreven en loodsen je zo door het proces heen van het installeren van een certificaat op een Exchange 2007 CAS server.

 open

Gepost in Exchange 2007 ~ 2 Reacties

Zo eindelijk tijd gehad om Exchange te upgraden naar SP2 en Exchange 2010 RC er eens bij te installeren. Opzich ging het allemaal vrij soepel. Het enige probleem waar ik tegenaan liep was een foutmelding wanneer ik via server configuration de CAS server opende. In dit geval was de volgende melding zichtbaar: “Unable to create IIS (Internet Information Services) Directory Entry. Error Message is: Access is denied. HResult =-2147024891.

Na wat speurwerk op internet kwam ik de oplossing tegen. Het probleem werd veroorzaakt doordat de groep Exchange Trusted Subsystem geen lid was van de local administrator groep op de Exchange 2007 servers.

Nadat ik dit had aangepast en de betreffende servers had gereboot was dit probleem verholpen en kon ik dus verder gaan met het testen van Exchange 2007 SP2 i.c.m. Exchange 2010 RC. In sommige gevallen kan het nodig zijn om alle Exchange servers te rebooten.

Maar waarom de groep Exchange Trusted Subsystem? Deze groep is geintroduceerd in Exchange 2010, is van het type universal en heeft lees/schrijf rechten op de Exchange objecten in een Exchange organisatie. Wanneer je via de EMC via de menu’s navigeert worden er onderwater Powershell commando’s uitgevoerd met een gebruikersaccount welke lid is van deze groep. Om dit mogelijk te maken dient ervoor gezorgd te worden dat de groep Exchange Trusted Subsystem voldoende rechten heeft op de betreffende objecten.

Gepost in Exchange 2007 ~ Geen Reactie