Exchange 2003

Het Exchange 2013 alfabet: Client Access Server

Posted by Johan Veldhuis on 07-02-2013
Posted in: Exchange 2003. Tagged: , . Leave a Comment

Dit is het 3de blog in de Exchange 2013 ABC serie. In deze blog kijken we naar het Client Access Server component. Laten we eerst eens kijken naar een klein stukje geschiedenis van client access in vorige versies.

Geschiedenis

In Exchange 2003 konden clients via twee manieren verbinden:

  • Direct naar de  Back-end server
  • Via de Front-end server welke de connectie proxied naar de  Back-end server

Vanaf Exchange 2007 besloot Microsoft een aparte server rol te introduceren die verantwoordelijk was voor het afhandelen van de client access genaamd de Client Access Server (CAS). Deze server kon geïnstalleerd worden:

  • Als aparte server
  • Op dezelfde server als de Hub Transport Rol
  • Op dezelfde server als de  Hub Transport en Mailbox Role ook wel bekend als de multirole server (alleen toegestaan als clustering niet werd gebruikt)

In Exchange 2010 bleven de aparte rollen bestaan maar was er een grote verandering in de ondersteuning van het installeren van meerdere rollen op één server. Vergeleken met Exchange 2007 werd het nu wel ondersteund om zowel de CAS, Hub Transport als Mailbox Server rol op één server te installeren ook als de Mailbox Server onderdeel is van een Database Availability Group (DAG). Dit creëerde de volgende installatie mogelijkheden:

  • Op een aparte server
  • Op dezelfde server als de Hub Transport Rol
  • Op dezelfde server als de Hub Transport en Mailbox Server ook wel bekend als de multirole server

Exchange 2013

Nu we hebben gekeken naar een stukje geschiedenis is het tijd om te kijken hoe Microsoft het e.e.a. heeft opgelost in Exchange 2013. Het lijkt erop dat men het Client Access deel heeft geupdate zodat het met de architectuur van Exchange 2003 te vergelijken is.

Het Client Access deel van Exchange 2013 bestaat uit twee onderdelen:

  • CAS rol
  • Mailbox Server rol

Laten we er wat dieper op in zoomen. De CAS rol van Exchange 2013 bevat drie componenten:

  • Client access
  • SMTP
  • UM Routing

Wat gebeurd er als een verzoek van een client bij de CAS aankomt? Het client access component authenticeerd de sessie en proxied het request vervolgens naar de Mailbox Server waar de actieve copy van de database op is geplaatst. Clients zullen nooit een directe connectie maken naar de componenten die onderdeel zijn van Mailbox Server rol. Alle connecties worden gemaakt via het client access component op de CAS rol.

Dit is slechts één van de veranderingen in Exchange 2013. De meest belangrijke aanpassing is dat client geen gebruik meer maken van RPC over HTTP om connectie op te zetten naar de server maar connectie maken via RPC over HTTP. Dit heeft enkele voordelen waaronder:

  • Clients gebruiken alleen nog maar HTTPS om verbinding te maken naar Exchange dus er hoeven geen grote poort reeksen opengezet te worden op de firewall
  • HTTPS heeft minder moeite met netwerk verbindingen waar men last heeft van hoge latency

Laten we eens verder kijken naar bovenstaande punten. In sommige gevallen wordt er een firewall geplaatst tussen de clients ende server. Alhoewel je het aantal poorten kunt limiteren die gebruikt worden voor RPC zoals in dit artikel beschreven. Vereist dit nog steeds dat er meerdere poorten worden geopend. Nu Microsoft heeft besloten om gebruik te gaan maken van RPC over HTTP is het openen van poort 443 voldoende om toegang te krijgen tot de resources van Exchange. Opgemerkt dient te worden dat hier wel enkele aanpassingen voor dienen uitgevoerd te worden. Het Offline Address Book is namelijk standaard beschikbaar via poort 80. Door een configuratie wijziging is het echter mogelijk dit ook via HTTPS beschikbaar te stellen.

Het tweede punt zal je niet vaak tegen komen op LANs: latency. Dit heeft een grote impact op RPC over TCP maar RPC over HTTPS kan hier beter mee omgaan alhoewel je natuurlijk het liefst zo min mogelijk latency hebt binnen je LAN.

Een andere aanpassing in Exchange 2013 is een aanpassing in de namespaces die benodigd zijn voor de omgeving. In een site resilient Exchange 2010 omgeving kan het aantal namen wat nodig is voor de omgeving uitkomen op totaal 8 namen. Twee van deze namen waren voor de CAS Array. Deze namen werden ingesteld als RPC Client Access Server op de databases en waren zichtbaar in het Outlook profiel van de gebruiker:

In Exchange 2013 maken we geen gebruik meer van de RPC Client Access Server parameter. In plaats van verbinding te maken met de CAS Array naam maken we verbinding via het volgende: MailboxGUI@corp.local.

Maar wat is het voordeel om via deze manier te verbinden? Misschien herken je deze pop up nog wel:

In Exchange 2013 is dat verleden tijd. Dit omdat de server waarde niet meer zal wijzigen. Besluit een beheerder dus om een mailbox te verplatsen dan zal de gebruiker niet meer gevraagd worden om Outlook te herstarten.

Load Balancing

En zijn er nog wijzigingen in load balancing? Ja er zijn een aantal wijzigingen. In vorige Exchange versies moest een load balancer geconfigureerd worden met session affinity en diverse protocollen maakten gebruik van layer 7 voor load balancing. In Exchange 2013 maken we alleen nog maar gebruik van layer 4 load balancing. Daarnaast is session affinity niet meer nodig. Dit omdat het effect minimaal is als een client via een andere Client Access server verbinding maakt met Exchange. De Mailbox Server is namelijk verantwoordelijk voor rendering van bijvoorbeeld OWA. Gaat de sessie verloren op de load balancer en wordt er een nieuwe sessie opgezet via een andere CAS dan zal deze bij dezelfde Mailbox Server uitkomen.

Maar hoe werkt de authenticatie dan? Nadat een gebruiker is ingelogt wordt er een authenticatie cookie gegeven aan de gebruiker die geencrypt is met het CAS SSL certificaat. Wanneer een client connectie maakt via een andere CAS zal deze CAS de authenticatie cookie decrypten. Voor dit proces is het wel vereist dat alle CAS gebruik maken van hetzelfde SSL certificaat.

Hier eindigt het derde blog in de Exchange 2013 ABC serie. In dit blog hebben we gekeken naar het Client Access Server component. In het volgende blog zullen we kijken naar de Database Availability Group in Exchange 2013. Onderstaand zijn enkele links te vinden naar sites met meer informatie over de Client Access Server.

Handige links:

Robert’s Rules of Exchange: Multi-Role Servers:
http://blogs.technet.com/b/exchange/archive/2011/04/08/robert-s-rules-of-exchange-multi-role-servers.aspx

Exchange 2013 Client Access Server:
http://blogs.technet.com/b/exchange/archive/2013/01/25/exchange-2013-client-access-server-role.aspx

Het einde van ForeFront Protection for Exchange (FPE) wat zijn de gevolgen?

Posted by Johan Veldhuis on 26-09-2012
Posted in: Exchange 2003. Tagged: , . Leave a Comment

Afgelopen zaterdag hebben we de 8ste aflevering van de TheUCArchitects opgenomen. Eén van de onderwerpen was de aankondiging van Microsoft over TMG en ForeFront Protection for Exchange.

Omdat het een leuke discussie was over de consequenties voor zowel reverse proxies als antivirus besloot ik hier een blog over te schrijven. In deze blog kijken we naar het antivirus deel omdat dit het deel is waar nog maar weinig discussies over zijn gevoerd.

Laten we beginnen met een korte beschrijving wat ForeFront Protection for Exchange eigenlijk is. Het kan gebruikt worden om zowel bericht verkeer als instore scanning uit te voeren. ForeFront kan daarbij gebruik maken van diverse A/V engines om een bericht te scannen. Dit heeft als voordeel dat mocht een pattern van één van de A/V engines nog niet up-to-date zijn het misschien wel wordt gedetecteerd door een andere engine die het pattern wel bevat. Het nadeel hiervan is dat het redelijk veel resources kost dus houd hier rekening mee tijdens de sizing van je Exchange omgeving.

Naast het on-premises product heeft Microsoft ook nog een Vloud variant ForeFront Online Protection for Exchange (FOPE). Deze oplossing scant alleen berichten die verstuurd worden naar je mailserver en ontvangen worden van je mailserver.

Vorige week heeft Microsoft aangekondigd te stoppen met diverse ForeFront producten waaronder ForeFront products among them ForeFront Protection for Exchange.

Waarschijnlijk wil Microsoft zijn klanten naar de FOPE pushen maar bevat dit wel alle features die ForeFront Protection for Exchange bevat? Het antwoord is redelijk eenvoudig, nee het bevat niet al deze features.

Laten we beginnen met het scannen van de mailboxen ook wel instore scanning genoemd. Deze feature heeft het voordeel dat je zowel realtime, handmatige als gescheduled een A/V scan op de mailbox content kan uitvoeren. Dit kan bijvoorbeeld nodig zijn wanneer er een uitbraak is of als additionele taak tijdens het onderhoud één keer per maand.

De 2de feature is het scannen van mail verkeer tussen interne clients onderling. Omdat dit niet via de cloud verloopt kan dit alleen worden gedetecteerd door een A/V oplossing op je Hub servers waar een additionele transport agent deze scanning zal uitvoeren. Bij een bedrijf beschikken alle clients meestal over een lokale A/V oplossing dus mogelijk wordt het virus hierdoor gevonden.

Misschien heb je al tijd gehad om te kijken naar de Tech Preview van Exchange 2013 wat standard al antispam en antimalware functionaliteiten biedt. Vooral de antimalware feature kan voor veel bedrijven misschien een interessante optie zijn. Deze feature voegt enkele basis antimalware functionaliteiten toe aan de Exchange omgeving om deze te beschermen tegen malware. Omdat het product nog niet RTM is kan dit nog wijzigen.

De antimalware feature is standard ingeschakeld en kan worden gecombineerd met de message filtering in de cloud. Standaard worden berichten die al gecontroleerd zijn door de hosted email filtering service niet nogmaals gecontroleerd wanneer deze worden afgeleverd bij de on-premises servers. Deze configuratie kan echter aangepast worden zodat het bericht zowel door de hosted email filtering service als door de antimalware feature van Exchange 2013 wordt gescant. Voor zover ik hebben kunnen ontdekken maakt deze feature geen gebruik van additionele engines net als ForeFront Protection for Exchange.

Daarnaast is ook de instore scanning functionaliteit niet beschikbaar, alleen berichten die verzonden/ontvangen worden door de transport servers worden gecontroleerd. Acties die genomen kunnen worden zijn:

  • Block entire message
  • Delete attachments and use either the default or customer alert

Zoals je kunt zien geen optie om berichten in quarantaine te plaatsen het is of het complete bericht verwijderen of alleen de attachments.

Voor bedrijven die features zoals de quarantaine, meerdere av-engines, onstore scanning etc. toch willen hebben blijft maar één mogelijkheid over een 3rd party product. Op dit moment heb ik nog geen leverancier kunnen ontdekken die al een beta versie heeft uitgebracht voor Exchange 2013 Tech Preview. Maar dit zal slechts een kwestie van tijd zijn voordat de leveranciers komen met een oplossing die ondersteuning biedt voor de nieuwe Exchange.

Wat de toekomst zal brengen? Dat is slechts een kwestie van tijd, laten we wachten totdat Exchange 2013 RTM is en we zullen zien of er in de uiteindelijke versie nog aanpassingen op gebied van antimalware zijn.

 [JV1]Officiele statement nog opzoeken

Exchange Virtual Server kan niet verwijderd worden

Posted by Johan Veldhuis on 10-06-2011
Posted in: Exchange 2003. Tagged: , . Leave a Comment

Tijdens het verwijderen van een Exchange 2003 cluster liep ik tegen het probleem op dat de Exchange Virtual Server niet verwijderd kon worden uit de Cluster Administrator.

In het event log waren geen vreemde events terug te vinden. Omdat het verwijderen van een Exchange Virtual Server een cluster gerelateerde taak is, is de volgende stap het onderzoeken van het cluster log. Dit bestand is terug te vinden in de volgende directory c:\windows\cluster directory.

Wanneer je het log bestand bekijkt zie je dat er diverse instellingen worden gecontroleerd voordat de Exchange Virtual Server verwijderd wordt

[11:21:42] Leaving ScTestAceOnObject
[11:21:42] ANONYMOUS LOGON does have READ permissions for MDB objects on the organization
[11:21:42] Checking to see whether the Exchange Domain Servers group has been DENIED Receive-As permissions on the Servers container(s)
[11:21:42] Checking the ACL on the Servers container in the admin group “First Administrative Group”
[11:21:42] Entering ScTestAceOnObject
[11:21:42] Attempting to get DOB for DN “/dc=LOCAL/dc=Corp/cn=Configuration/cn=Services/cn=Microsoft Exchange/cn=Corp/cn=Administrative Groups/cn=First Administrative Group/cn=Servers”
[11:21:42] Attempting to read security descriptor from DOB
[11:21:42] Attempting to initialize CAce object
[11:21:42] Testing to see if given ACE is present
[11:21:42] Test succeeded; fACLPresent = TRUE, fExtraRights = FALSE
[11:21:42] The ACE tested for is present in the ACL of this object
[11:21:42] Leaving ScTestAceOnObject
[11:21:42] The Exchange Domain Servers group has been DENIED Receive-As permissions on the Servers container(s)
[11:21:42] The required permissions have already been set
[11:21:42] Leaving ScDetermineIfLocalDomainServerGroupHasAlreadyBeenACLedOnExchangeCT
[11:21:42] Entering ScFindRoutingGroupThatContainsServer
[11:21:42] Leaving ScFindRoutingGroupThatContainsServer
[11:21:42]  ScPRQ_ServerIsNotHomeServerForPostmasterOfNonEmptyOrg (f:\tisp2\admin\src\udog\excommon\prereq.cxx:2981)
           Error code 0X80072030 (8240): There is no such object on the server.
[11:21:42]  CCompServer::ScCheckEVSPrerequisites (f:\tisp2\admin\src\udog\exsetdata\components\server\compserver.cxx:1405)
           Error code 0X80072030 (8240): There is no such object on the server.
[11:21:42]  ScSetupExchangeVirtualServer (f:\tisp2\admin\src\udog\exsetdata\exsetds.cxx:1541)
           Error code 0XC103FC97 (64663): Setup encountered an error while checking prerequisites for the component “Microsoft Exchange Server”: 0X80072030 (8240): There is no such object on the server.
[11:21:42] Leaving ScSetupExchangeVirtualServer 

Eén van de dingen die gecontroleerd wordt zijn bijvoorbeeld de ACL’s. Naast de ACL’s wordt ook gekeken of de postmaster mailbox zich bevind op de server die verwijderd wordt. Het account dat gebruikt wordt om Exchange te installeren wordt standaard de postmaster. Als de mailbox niet gevonden kan worden, omdat de mailbox is verwijderd, zal het proces afgebroken worden.

Maar hoe kun je dit oplossen? De meest eenvoudige manier is het restoren van het account en de mailbox van de back-up. Als dit echter niet mogelijk is zal je de postmaster mailbox moeten toewijzen aan een ander account.

Om de mailbox toe te wijzen aan een ander account dien je gebruik te maken van ADSIEDIT. Zorg ervoor dat je voordat je aanpassingen gaat maken met ADSIEDIT een goede en recente back-up hebt van je Active Directory.

Wanneer je dit hebt gecontroleerd is het tijd om de aanpassingen te maken. Open de Configuratie partitie van de Active Directory en klap de volgende items open:

  • CN=Services
  • CN=Microsoft Exchange
  • CN=Organization Name, bijvoorbeeld Corp

Vraag de eigenschappen van CN=Global Settings op en zoek naar het attribuut MsExchAdminMailbox. Wanneer je naar de waarde van dit attribuut kijkt zul je zien dat dit een account is die is verwijderd:

In dit geval heeft het attribuut de waarde CN=Exchadmin\0ADEL:bbf20ca9-7def-4e0f-bdd9-f9107c1643d6,CN=Deleted Objects,DC=Corp,DC=local. De DEL betekent dat het object niet meer bestaat. Om dit op te lossen dient de waarde aangepast te worden naar een bestaande gebruiker, bijvoorbeeld CN=Postmaster,DN=ServiceAccounts,DC=Corp,DC=local.

 Nadat de AD replicatie heeft plaatsgevonden kun je de Exchange Virtual Server verwijderen via de Cluster Administrator tool.

De-installatie van Scanmail 8 verwijdert niet alles

Posted by Johan Veldhuis on 30-05-2011
Posted in: Exchange 2003. Tagged: , , . Leave a Comment

Tijdens het afbreken van een Exchange 2003 cluster liep ik tegen een probleem op na de de-installatie van Trend Micro Scanmail (SMEX) 8.0. Nadat de de-installatie voltooid was startte de Cluster administrator alleen nog maar op met een foutmelding. Een van de oorzaken was dat het resource object voor SMEX nog aanwezig was. Dit was eenvoudig te verwijderen middels de standaard procedure om cluster resources te verwijderen.

Echter ondanks dat dit resource verwijderd was bleef de cluster met een foutmelding naar voren komen. Toen ik verder ging kijken bleek dit door het resource type clusRDLL te komen wat nog aanwezig was.

Om dit resource type op te ruimen kun je gebruik maken van het cluster commando:

cluster restype clusRDLL /delete /type

Nadat dit commando was uitgevoerd was de foutmelding verdwenen en kon de Exchange 2003 Virtual Server verwijderd worden.

Overigens heeft Trend Micro hier een knowledge base artikel voor:

Uninstalling Scanmail for Exchange (SMEX) 8.0 from cluster servers open

MapiExceptionNotFound: Unable to delete mailbox

Posted by Johan Veldhuis on 14-05-2010
Posted in: Exchange 2003, Exchange 2010. Tagged: , , . Leave a Comment

Tijdens een cross-forest test-migratie van Exchange 2003 naar Exchange 2010 liep ik tegen onderstaande foutmelding aan:

Warning: Unable to update AD information for the source mailbox at the end of the move.  Error details: An error occurred while updating a user object after the move operation. –> Failed to find the address type object in Active Directory for address type “SMTP:AMD64″.
Failed to cleanup the source mailbox after the move.
Error details: MapiExceptionNotFound: Unable to delete mailbox. (hr=0x8004010f, ec=-2147221233)

Toen we gingen kijken bestond de mailbox inderdaad zowel in het oude forest als in het nieuwe forest. In dat geval heb je een redelijke uitdaging zeker als de mail eerst binnenkomt op de Exchange 2003 server en het homeMDB attribuut daar nog niet is geupdate. Mail wordt dan namelijk alleen maar afgeleverd in de Exchange 2003 omgeving en niet in de nieuwe omgeving wat dus inhoudt dat er mail niet aanwezig is in de nieuwe mailbox in de Exchange 2010 omgeving.

Om dit probleem te voorkomen dien je een hotfix op de Exchange 2003 omgeving te installeren, de hotfix is te vinden op onderstaande site.

open

Problemen met het verwijderen van een Exchange 2003 cluster

Posted by Johan Veldhuis on 14-04-2009
Posted in: Exchange 2003. Tagged: , , . Leave a Comment

Tijdens een van mijn forum bezoeken kwam ik een interessant probleem tegen. Iemand probeerde zijn oude Exchange 2003 cluster te verwijderen en liep tegen onderstaande foutmelding aan:

Found no Disk resource for the disk that contains the folder ‘W:\EXCHSRVR’

Wanneer echter in de Cluster Administrator gekeken werd was hier de resource niet zichtbaar, erg vreemd dus. Dus we moesten de resource verwijderen m.b.v. ADSIEDIT.

Voordat je zo’n actie uithaalt moet je natuurlijk wel eerst een backup maken van je AD voor het geval dat.

Vervolgens dien je de volgende stappen uit te voeren:

- open adsiedit
- kies connect to
- pas de het veld domain aan naar configuration
- klap CN=Configuration … open
- klap CN=services open
- klap CN=Microsoft Exchange open
- klap CN=First organization open
- klap CN=servers open
- klap CN=servernaam open
- klap CN=Information Store open

Controleer hier of de storage groups of databases nog verwijzingen hebben naar een database. In dit geval bleek dit niet zo te zijn en moesten we dus verder gaan zoeken. Het probleem bleek te zitten in een van de bovenliggende eigenschappen:

- vraag de eigenschappen op van de servernaam
- zoek de waarde MsExchDataPath op
- controleer of hier de betreffende verwijzing nog in voorkomt

Wanneer deze stappen zijn uitgevoerd kun je opnieuw proberen het Exchange 2003 cluster te verwijderen.

Exchange 2003 blijft dezelfde mail versturen

Posted by Johan Veldhuis on 04-03-2009
Posted in: Exchange 2003. Tagged: , . Leave a Comment

Vandaag weer een leuk Exchange issue’tje gehad. Op e.o.a. vage manier bleef een Exchange 2003 server dezelfde mails versturen. Zelfs als ze uit de queue werden gegooid in de Exchange System Manager. Aangezien dit de complete bandbreedte voltrok de limieten qua connecties etc. maar aangepast, echter zonder effekt.

Dus maar eens gaan zoeken wat nog meer mogelijkheden waren. Ik stuitte hierbij op een post op expert-exchange. Hierin werd geadviseerd met MFCMAPI de temp tabel leeg te maken. Hierin zouden namelijk de betreffende berichten staan.

Na dit uitgevoerd te hebben was dit issue inderdaad opgelost, onderstaand de stappen die je hiervoor moet doorlopen:

  • download en installeer MFCMAPI
  • kies session  en selecteer logon and display store tables
  • indien er meerdere profielen aanwezig zijn zal er gevraagd worden een profiel te selecteren, selecteer het profiel van de administrator
  • er zal nu een overzicht van de mailbox en public folders weergeven worden. Selecteer MDB en kies vervolgens de optie get mailbox table
  • er zal nu een overzicht weergeven worden van alle mailboxen in de betreffende mailstore. Zoek hier de mailbox van SMTP
  • zoek in het linkermenu de waarde Temp Tables
  • verwijder alle submappen onder de Temp Tables, wanneer er gevraagd wordt of de berichten hard delete moeten worden doe dit dan.
  • herstart de SMTP service