In een omgeving waar meerdere emaildomeinen gehost worden, is het opzetten van de Autodiscover service voor connecties vanaf het internet een lastige. Voor domain-joined clients zal de autodiscovery service gevonden worden door middel van het SCP attribuut op het CAS object in de Configuration Partition.

Op het internet heb je geen AD en zal Outlook DNS gaan querien op basis van de domeinnaam van het emailadres
dat je meegeeft. Hij zal dus verbinden in volgorde met:
 
https://domein.com/Autodiscover/Autodiscover.xml
https://Autodiscover.domein.com/Autodiscover/Autodiscover.xml
http://Autodiscover.domein.com/Autodiscover/Autodiscover.xml

Nu kan je in een AD omgeving werken met self-signed certificaten, maar op het internet MOET je een trusted certificaat hebben. Hier wringt dus meteen de schoen, want dan zal je, in normale omstandigheden, voor elk domein een eigen certificaat moeten hebben (of meerdere domeinen op 1 cert dmv Subject Alternative Names).

ECHTER... Outlook 2007 kan een HTTP redirect volgen.

Dus:
http://domeinA.com/Autodiscover/Autodiscover.xml
redirect naar
https://domeinB.com/Autodiscover/Autodiscover.xml

Dit is redelijk simpel op te zetten. Een van de manieren waarop je dit kan doen, ervanuit gaande dat we met IIS werken is de volgende:

1. (optioneel) Registreer een nieuw additioneel ip adres voor je webserver waar de redirection page op moet draaien. Deze is toe te voegen onder de 'Advanced' knop in je TCP/IP settings op je NIC.
2. Maak vervolgens een nieuwe website aan in IIS en laat deze luisteren op je nieuwe IP. 

   (JE kan ook host headers gebruiken als je geen extra ip hebt. Laat de site dan luisteren luisteren naar autodiscover.domein.com.
   Let wel: als je met host headers wilt werken zal je voor elke additioneel domein een nieuwe host header moeten toevoegen met dezelfde opmaak. Dus: autodiscover.domeinA.com, Autodiscover.domeinB.com etc etc)

   

3. Maak vervolgens met notepad een autodiscover.xml bestand aan in de webdirectory die je hebt toegewezen aan deze website. Laat deze gewoon leeg.
4. Laat dit bestand redirecten naar je Autodiscover service achter de ExternalURL op je Client Access server (vb: https://ExternalUrlCas.domeinB.com/autodiscover/autodiscover.xml ) door in IIS de properties van het bestand te openen en connecties via de 'File' tab door te zetten.
   

Nu is in principe de redirect site klaar. Om nu voor andere domeinen mogelijk te maken om de autodiscover service te gebruiken, moet je een A record aanmaken in de DNS zone van je additionele domeinen met het ip adres van je webserver waar je redirect site op draait (kan btw ook met een CNAME record, echter moet je dan het ip adres van je redirect website registeren in DNS, als je niet met host headers werkt, iets wat ik persoonlijk geen nette oplossing vind).

Op deze manier zal een Outlook client via DNS de Autodiscover service vinden en hoef je alleen een geldig certificaat aan te vragen voor de ExternalURL van je client access server. De gebruikers krijgen echter wel een waarschuwing dat ze redirected worden en deze moeten ze accepteren.

 Enjoy!! :)

NLB binnen Windows 2003 is een veelgebruikte manier om services redudant te maken en/of te load balancen. Het is standaard beschikbaar in elke versie van Windows 2003 server; dit in tegenstelling to Cluster Services welke in de standard en web editions van Windows 2003 server niet beschikbaar is.

In Exchange 2007 kan je een aantal diensten aanbieden via NLB. Owa, web services, imap4 en pop3 kan je prima achter een NLB cluster zetten. De hub/edge transport role, mailbox server role en Unified messaging role kan je niet gebruiken i.c.m. NLB, of toch wel? Via een klein trucje kan je toch een hub transport server achter NLB zetten als je de Receive Connectoren voor communicatie met andere hub transports maar niet via NLB aanbiedt. Dit omdat de hub transports onderling mutual TLS authentication gebruiken, en NLB problemen veroorzaakt met het uitwisselen en valideren van de certificaten. Ook heeft de hub transport role zelf geen notie van een cluster en zal daardoor een set exchange servers nooit als een cluster benaderen. NLB is in de meeste gevallen ook helemaal niet nodig omdat Hub transports in dezelfde site (wat btw ook een vereiste is voor een NLB cluster. Een NLB cluster over subnets heen bestaat (nog) niet) zelf al load balancen en fault tolerant zijn. Echter wanneer je andere systemen hebt die verbinding maken via SMTP met een hub transport server (bv: fax of sms diensten), kan het handig zijn om een stukje load balancing en fault tolerance in de infrastructuur aan te brengen. 

Dit artikel zal een beschrijving geven hoe je dit voor elkaar krijgt:

Voordat we met het configureren beginnen is het handig even kort stil te staan bij hoe NLB ongeveer werkt. NLB werkt door middel van een filterdriver die geladen wordt, waarmee het netwerk connecties getoetst kunnen worden aan de rules die opgesteld kunnen worden wanneer je NLB configureert. Deze rules bepalen of UDP of TCP verkeer voor een bepaalde port wel of niet tot NLB 'enabled' verkeer behoort. NLB werkt in Unicast of Multicast mode, wat wil zeggen dat de netwerkkaarten die gebruikt worden OF 1 (unicast) MAC address krijgt of meerdere (multicast) MAC addressen kan gebruiken. Wanneer NLB in unicast wordt opgezet, wordt het MAC address van de netwerk kaart vervangen door een MAC address dat iedere node in het cluster zal gebruiken. In multicast wordt het gezamenlijke MAC address toegevoegd aan de netwerkkaarten. Doordat meerdere hosts gebruik maken van hetzelfde MAC address kan deze netwerk kaart niet meer gebruiken voor interhost communicatie (dit omdat source en dest MAC hetzelfde zijn. Zelfs in Multicast mode kan het zijn dat je tegen dit probleem aanloopt). Het is daarom ten sterkste aan te raden een extra netwerk kaart te gebruiken voor NLB.
Wanneer je nu het NLB cluster aanmaakt dan configureer je een clusterIP en een clusterDNS (de laatste moet je wel zelf nog toevoegen in DNS). Verder kan je aangeven welke hosts in het cluster zijn opgenomen, welk verkeer je wilt filteren, of je het wilt load balancen of je alleen fault tolerant wilt zijn en of je server affinity wilt gebruiken. Dit laatste laat connecties (binnen een bepaald tijdframe) van ip addressen of complete subnets altijd door dezelfde host afhandelen. Dit is bijvoorbeeld handig voor als je met applicaties werkt via een SSL tunnel. Zonder affinity zou het aantal SSL sessies explosief stijgen. Wanneer je port 80 achter NLB hebt zitten en je gebruikt je browser om http://nlb.domein.com te benaderen, zullen de netwerk packets gerouteerd worden tot aan de laatste router of multi-layer switch. Hierna zullen de frames op de Datalink laag (LEVEL 2 in het OSI model) op basis van het MAC address afgeleverd worden bij de uiteindelijke host. Echter het MAC address wordt gebruikt op alle hosts. Een switch kan hier niet mee omgaan. Achter elke switch port moet een uniek MAC address zitten. Een switch bouwt zijn ARP table op door de frames te bekijken van de verbonden hosts en via ARP requests, en neemt de source MAC addressen op in de table. Als de switch een frame krijgt en het destination MAC address niet kan vinden in zijn table, zal hij het frame over alle poorten broadcasten. NLB maakt hier sneaky gebruik van. Op alle uitgaande frames van de NLB NIC wordt het MAC address aangepast. Alle NLB cluster MACs zijn hetzelfde opgebouwd, waarbij de tweede 8 bits (in HEX) altijd BF is. Echter voor de uitgaande frames wordt deze tweede set 8 bits aangepast aan de priority dat een node in het cluster heeft (01, 02, 03, 04 etc etc). Dit maakt dat de ARP tabel alleen de aangepaste MAC addressen bevat. Als er dus een frame komt dat bestemt is voor het cluster, dan zal hij deze broadcasten over alle porten.. Via het gezamenlijk algoritme dat de NLB nodes onderhouden, antwoordt de node die op dat moment 'aan de beurt is'. Door dit principe staat NLB erom bekend switches te kunnen flooden. Hier zijn tweaks voor.

Zo, dat is NLB in een nutshell :)

Volg de volgende stappen om NLB te activeren voor je Exchange services:

1. Installeer een tweede netwerk kaart in je systemen.
2. Zorg dat de primaire netwerk kaart als eerste in de binding order komt en verwijder de 'File and printer sharing' en 'Client for MS networks' bindings van de tweede netwerk kaart.
3. Start NLBMGR op vanuit een command shell.
4. Maak een cluster aan in UNICAST mode (in VMWARE moet je multicast gebruiken, anders werkt het niet) en voeg, wanneer je een host toevoegt, de tweede netwerkkaart toe.
5. Maak vervolgens rules aan voor TCP porten 80, 443, 110, 143 en 25. Port 80 en 25 hebben geen host affinity nodig. Port 110, 143 en 443 stel je in met single affinity. (wanneer je pop3 of imap unsecure gaat aanbieden, kan je 110 en 143 ook zonder affinity instellen). Zet de rule in 'Multiple Hosts' mode, wat ervoor zorgt dat alle hosts meedoen in het cluster.
   
6. Maak nu een nieuwe receive connector aan op elke NLB node en laat deze alleen luisteren op het cluster ip adres. Zorg ervoor dat de default connectors luisteren op het primaire ip adres. Pas ook de FQDN response aan van alle receive connectors in het cluster. Om een nieuwe connector te maken:
   Voorbeeld: New-ReceiveConnector -Server:'Node1' -Name:'NLB Connector' -Type:'Costum' -Bindings:'192.168.1.100:25' -fqdn:'Cluster.fqdn.domein.com' -RemoteIpRanges:192.168.1.10 -PermissionGroups:'AnonymousUsers' -AuthMechanism:'None'

   Dit maakt op Node1 een connector aan met de naam 'NLB Connector' die luistert op clusteripadres 192.168.1.100 port 25, en antwoordt met cluster.fqdn.domein.com in de SMTP banner (220 cluster.fqdn.domein.com Microsoft ESMTP MAIL service ready at (datum)). Het accepteert anonymous verbindingen van 192.168.1.10. Om ook nog echt te kunnen relayen moet je echter nog het ms-Exch-SMTP-Accept-Any-Recipient recht toekennen aan 'ANONYMOUS LOGON' wat het security principle is voor anonieme verbindingen. Dit recht stelt je in staat om email te verzenden aan iedere ontvanger en niet alleen aan accepted domains.
   Voorbeeld: Get-ReceiveConnector 'Node1\NLB Connector' | add-adpermission -User 'NT AUTHORITY\ANONYMOUS LOGON' -ExtendedRights ms-Exch-SMTP-Accept-Any-Recipient
   
   VERGEET AUB NIET DE BINDING VAN DE ANDERE RECEIVE CONNECTORS TE VERANDEREN NAAR HET PRIMAIRE IP ADDRESS

Probeer nu OWA te benaderen op https://cluster.fqdn.domein.com/owa en de nieuwe SMTP connector via telnet clusterip 25. Als het goed is moet nu alles werken (door de banner te veranderen op de verschillende receive connectoren kan je zien dat het werkt).

Ik zeg... aan de slag!! ;)

In Exchange 2007 RTM heb ik in sommige situaties problemen zien ontstaan waarbij gebruikers hun Out of Office meldingen niet meer konden aanpassen. OOF responses bevatte keer op keer een verouderde melding. In SP1 ben ik het vooralsnog niet tegengekomen, maar dat wil niet perse zeggen dat het probleem daar niet meer bestaat, aangezien er geen gedocumenteerde fix is.

Mocht je dit probleem aantreffen doe dan het volgende op een doos waar Outlook geinstalleerd staat:

1. Download MFCMapi.
2. Creeer een mailprofile voor de desbetreffende mailbox.
3. Start MFCMapi.
4. Klik op OK om het infovenster te sluiten en selecteer 'Session' > 'Logon en Display Store table'.
5. Selecteer het zojuist aangemaakt mailprofile.
6. Dubbel-Klik de juiste mailbox uit de bovenste tabel:
   
7. Afhankelijk van hoe oud de mailbox is (pre-2003 of niet) moet je browsen naar 'Top of Information Store' of 'IPM_SUBTREE'.
8. Rechts-Klik de INBOX folder en selecteer 'Open Associated Contents Table'.
9. In het Window wat nu opent, krijg je een lijst met alle hidden messages zoals rules.
   Sorteer nu op de 'Message Class' kolom.
10. Zoek nu de items met Message Class 'IPM.Note.Rules.OOFTemplate.Microsoft':
    
11.  Rechts-Klik op de message(s) en selecteer 'Delete Message'
12. Selecteer de 2e optie uit de 'Delete Item' keuzelijst en klik 'OK'.

Probeer nu je OOF message te wijzigen. Als het goed is moet het weer werken.

 Suc6!!! :)

Ik ben nu al verscheidende malen onverklaarbare connectiviteitsproblemen met Exchange aan het troubleshooten geweest en keer op keer had dit te maken met features die geactiveerd zijn door het Scalable Networking pack van SP2. Deze update bevat uitbreidingen van de TCP/IP stack die nieuwe functionaliteit uit de NDIS 6 specificaties mogelijk maakt zoals:

• Receive Side Scaling (Multi-processor ondersteuning. In pre NDIS 6 drivers, werkt telkens slechts 1 CPU de interupts van de NIC af.)
• TCP Chimney offloading (offloaden van taken als headerparsing, timing calculaties en segmentatie van data)
• NetDMA (Directe toegang tot het geheugen voor NIC)

Klinkt allemaal geweldig, maar in de praktijk zijn er veel probleem mee zoals je hier en hier kan lezen. Voornamelijk het probleem waardoor gebruikers niet meer kunnen inloggen en event is er 1 die ik geregeld gezien heb:

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9646
Date: ...
Time: ...
User: N/A
Computer: ...
Description:
Mapi session "/o=.../ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=..."exceeded the maximum of 64 objects of type "session".

Daarnaast heb ik problemen gezien met applicaties die via MAPI verbinding proberen te maken met de NSPI port op Exchange servers en waarvan de connecties gewoon verbroken worden. Voorbeelden zijn Blackberry Enterprise Server en Symantec Enterprise Vault.
Op Blackberry ontstaan bijvoorbeeld Calendar Sync problemen doordat het process CalHelper.exe via CDO geen MAPI sessies meer kon opzetten. Een voorbeeld logknipsel is:

[40574] (01/31 19:02:31.501):{0x2090} CDO helper 068cf200 started, PID 5360
[30001] (01/31 19:02:31.830):{0x2090} CDOCalendar::Initialize - Code = 800406f9, WCode = 04f9, Code meaning = IDispatch error #1273,
[30002] (01/31 19:02:31.830):{0x2090} Server = server, Mailbox = /o=.../ou=.../cn=Recipients/cn=... Description = The information store could not be opened. [MAPI 1.0 - [MAPI_E_LOGON_FAILED(80040111)]]
[30180] (01/31 19:02:31.830):{0x2090} {...} CDOCalendar::Initialize - Error in call m_spCalendarFolder = m_spCDOSession->GetDefaultFolder
[40000] (01/31 19:02:31.830):{0x2090} CDO initializing failure in CDO helper 068cf200 (1)

Ook Enterprise Vault geeft soms problemen met het aanmaken van Archiving Tasks op Exchange 2007 servers. De melding in de event logs zijn:

Event Type: Error
Event Source: Enterprise Vault
Event Category: Archive Task
Event ID: 3305
Date: ...
Time: ...
User: N/A
Computer: ...
Description:
The Task 'Mailbox Archiving Task for Server' failed to log on to Exchange server 'Server' using mailbox 'smtp:email@domein.com. Please ensure that the server is running and that the Vault account has sufficient permissions on the server.

De problemen lijken telkens op Authenticatie problemen, maar in werkelijkheid zie je TCP connecties bijna onmiddelijk gebroken te worden, wanneer de systemen proberen contact te maken.

Probeer dus eerst TCPChimney Offloading uit te schakelen via Netsh int ip set chimney DISABLED. Ondanks wat de artikelen zeggen, adviseer ik toch een reboot. Als de problemen weer optreden probeer dan RSS en NetDMA uit te zetten via het register:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableTCPA"=dword:00000000
"EnableRSS"=dword:00000000

Success!

Blackberry Enterprise Server 4.1 MR4 geeft problemen met calendar items in combinatie met Exchange 2007 SP1.
Wanneer een meeting request ontvangen wordt op de Blackberry, flagt het device deze als 'Tentatively Accepted'.

In Outlook zie je het volgende op het meeting request bij de uitgenodigde met een Blackberry:

 Degene die de meeting georganiseerd heeft, heeft echter geen response gekregen:

Dit probleem treedt op ongeacht welke handheld je hebt. Het probleem is bekend bij RIM, echter het response is minder leuk: