Just do I(nformation)T(echnology) : Exchange 2007

Update Rollup 7 voor Exchange 2007 SP1

mpriem — Fri, 20 Mar 2009 13:40:31 GMT

Update rollup 7 voor Exchange 2007 SP1 is vrijgegeven. De release notes zijn te vinden op http://support.microsoft.com/kb/960384
Het dowload package is te vinden op http://www.microsoft.com/downloads/details.aspx?FamilyID=2074fefd-fa1a-4c3e-bf72-94585e454150

Voor het laatste ontwikkelingen betreffende Exchange updates is er een Updates forum. Neem een kijkje om te zien of er nog known issues zijn: http://social.technet.microsoft.com/Forums/en-US/exchangesoftwareupdate/threads/

Organizational Forms Library Exchange 2007

mpriem — Sat, 10 May 2008 12:37:00 GMT

In Exchange 2000|3 kon je nog heel gemakkelijk een Organisational Forms Library aanmaken via de GUI. In Exchange 2007 gaat dat zo makkelijk niet meer. Hier moet je een enigsinds lastige procedure volgen.

Voordat je begint, moet je eerst HIER MFCMapi downloaden.

Vervolgens doe je het volgende:

1. Voer het volgende powershell commando uit in de Exchange shell:

New-PublicFolder -Path "\NON_IPM_SUBTREE\EFORMS REGISTRY" -Name "Organizational Forms Library"

2. Configureer een mapi profiel.

3. Open MFCMapi en selecteer 'Session' > 'Logon and Display Store Table'

4. Dubbelklik 'Public Folders' in het bovenste pane.

5. Browse naar "\NON_IPM_SUBTREE\EFORMS REGISTRY"

6. In de linkerkolom selecteer je 'EFORMS REGISTRY' en kies je 'Modify Extra Properties' uit het 'Property Pane' menu.

7. Kies voor ADD > 'Select Property Tag' > 'PR_EFORMS_LOCALE_ID'.

8. Selecteer twee maal OK.

9. DubbelKlik 'PR_EFORMS_LOCALE_ID' en vul je Taalcode in. Taalcodes zijn HIER te vinden.

10. Nu de folder geconfigureerd is, kan je de benodigde permissies zetten met de 'Set-PublicFolder', 'Add-PublicFolderClientPermission' en 'Add-PublicFolderAdministrativePermission' cmdlets...

MSExchangeIS event id 9874 (icm Forefront)

mpriem — Wed, 23 Apr 2008 17:44:00 GMT

Op verschillende plaatsen heb ik meldingen gelezen over bedrijven die last hebben van eventid 9874:
Event Type: Warning Event Source: MSExchangeIS Event Category: Virus Scanning Event ID: 9874 Date: 3/17/2008 Time: 12:23:57 PM User: N/A Computer: <servername> Description: Unexpected error 0x50a occurred in "EcProcessVirusScanQueueItem" during virus scanning. Mailbox Database: /o=<orgname>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=<servername>/cn=Microsoft Private MDB Folder ID: 1-24 Message ID: 1-D616AA3D

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Dit event heeft te maken met dat Forefront bepaalde instellingen in het register niet goed kan verwerken. In mijn geval had het te maken met Background scanning opties die niet aanwezig waren in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\VirusScan].

Dit is de juiste inhoud van de key voor een server met alleen de mailboxrole (De ontbrekende DWORDS zijn vet gedrukt):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\VirusScan]
"Library"="C:\\Program Files (x86)\\Microsoft Forefront Security\\Exchange Server\\FSEVsapiEx.dll"
"BackgroundScanning"=dword:00000000
"ProactiveScanning"=dword:00000000
"ScanRTF"=dword:00000001
"ScanTimeout"=dword:00000258
"EnableScanDeletion"=dword:00000001
"OnAccessScanningRollingLowerAgeLimit"=dword:00360d80
"ReloadNow"=dword:00000000
"Enabled"=dword:00000001
"OnAccessThresholdVersion"=dword:00000001
"BackgroundScanningIgnoreStamp"=dword:00000001
"BackgroundScanningOnlyUnscanned"=dword:00000001
"BackgroundScanningAttachmentMessagesOnly"=dword:00000001

Dit kwam omdat de Background scanning job een keer gedraaid moet hebben om deze key op de juiste manier te vullen. Dit doe je door in Forefront het schedule voor de background scanning job aan te passen dat de job in ieder geval 1 keer draait.

Microsofts best practice is om deze job wekelijks te draaien en dan alleen unscanned berichten te scannen, ontvangen in de laatste week, met attachment.

Meeting forward notification crashed Outlook

mpriem — Mon, 11 Feb 2008 18:43:00 GMT

In Exchange 2007 heb je een nieuwe functie die ervoor zorgt dat de organisator van een meeting een forward notificatie krijgt als zijn meeting geforward wordt naar een andere mailbox.

Outlook 2003's "New Mail Desktop Alert" kan daar echter niet goed mee omgaan en crashed Outlook 2003 als deze niet op SP3 zit.

Oplossingen/Workarrounds zijn dus:

Disable de "New Mail Desktop Alert" via Options > Preferences > E-Mail Options > Advanced E-Mail Options> uncheck "Display a New Mail Desktop Alert".
Uitrollen SP3 voor Outlook 2003
AV of Antispam oplossing dusdanig configureren dat de Meeting forwards niet aankomen

Exchange 2007 SP1 veroorzaakt problemen met Calendar items icm Blackberry

mpriem — Fri, 04 Jan 2008 18:42:00 GMT

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:

"Thank you for contacting BlackBerry Customer Support.

The issue you have found has been identified by the BlackBerry Development Team and has been flagged to be addressed. The SDR relating to this is SDR144817 and all I can advise is you check the next release of the BlackBerry Enterprise Software if this has been fixed and included it will be in the release notes"

Out of Office probleem Outlook 2003 en Exchange 2007

mpriem — Fri, 04 Jan 2008 18:41:00 GMT

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:

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

Windows 2003 SP2 Scalable Networking pack problemen

mpriem — Fri, 04 Jan 2008 18:40:00 GMT

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!

NLB voor zowel de Client Access Server als de Hub Transport

mpriem — Wed, 02 Jan 2008 18:39:00 GMT

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:

Installeer een tweede netwerk kaart in je systemen.
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.
Start NLBMGR op vanuit een command shell.
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.
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.
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!! ;)

HTTP redirect voor Autodiscover Service

mpriem — Wed, 02 Jan 2008 18:37:00 GMT

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:

(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.
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)
Maak vervolgens met notepad een autodiscover.xml bestand aan in de webdirectory die je hebt toegewezen aan deze website. Laat deze gewoon leeg.
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!! :)

Format-List * ??!?

mpriem — Mon, 31 Dec 2007 18:36:00 GMT

Het is mij opgevallen dat format-list soms een vreemd gedrag vertoont. Het toont niet altijd alle properties. Een goed voorbeeld is het volgende commando

Get-ExchangeCertificate | fl

Vergelijk de output maar eens met:

Get-ExchangeCertificate | fl *

Dit zou volgens de syntax niets uit mogen maken. Ik heb een vraag uitstaan bij MS, maar bij voorkeur kan je dus beter de asterix gebruiken.

EDIT:

Mow van http://thepowershellguy.com was zo vriendelijk uit te leggen hoe de spreekwoordelijke vork in de steel steekt met format-list.. Zo zie je maar.. Je leert elke dag weer wat bij.

Dank je MOW!!

Zijn reactie is te vinden onder dit artikel, maar voor de volledigheid zal ik het opnemen in het artikel:

Wanneer je geen * gebruikt word de default format data gebruikt.
Dit zijn de properties die bij default worden getoond.
de defaults zijn / worden opgeslagen in format files :

notepad $PSHOME\DotNetTypes.format.ps1xml

wanneer het type in deze file(s) gevonden wordt wordt deze format data gebruikt voor de default output :

een goed voorbeeld is :

dir | ft
dir | ft *

hier is de defenitie the vinden in :

notepad $pshome\FileSystem.format.ps1xml

dir $PSHOME *.ps1xml

je kunt met de update-formatdata Cmdlet ook je eigen “view’s” voor objecten toevoegen, de default formatfile is “gesigned” en kan beter niet aangepast worden.

doe er iets leuks mee ,

Groeten /\/\o\/\/

Outlook Web Access 2007 redirection page

mpriem — Wed, 19 Dec 2007 18:33:00 GMT

Heb je in Exchange 2007 wel eens OWA redirection geprobeert in combinatie met forms based authenticatie. Dat is dus niet echt geweldig. Het vereist je om twee maal in te loggen en daartussen moet je nog een keer op een link klikken. Ook moet je je 403.4 error page aanpassen om initieel je gebruikers door te verwijzen naar de OWA virtual directory achter port 443. Allemaal erg omslachtig.

Voor deze mensen heb ik een oplossing...

In de SDK voor Exchange 2007 SP1 vond ik een mooie Autodiscover proxy class, waarmee je heel gemakkelijk de autodiscover service kon aanspreken. Alle logica voor het polsen van het Service Connection Point en anders DNS staat daarin. Dit bracht mij op het idee om even quick en dirty in ASP.net een redirection page te maken waarmee op basis van de Windows Credentials een user doorgestuurt wordt naar de juiste CAS.

Het is heel simpel te implementeren:

Creeer een directory voor een nieuwe website (bv: C:\InetPub\OwaRedirect)
Pak de Owa Redirection zipfile uit in deze directory.
Creeer in IE een nieuwe website, waar alleen Windows Integrated Authentication wordt toegestaan en zet de permissies op 'Read' en 'Run scripts'.
Bind de site aan een secondary IP of werk met host headers (zorg dat als je met ip binding werkt, je ook de default web site bind aan een bepaald IP)
Creeer een A record voor deze site (je kunt deze site op meerdere servers hosten en met DNS round Robin werken; werkt uiteraard ook in NLB).

Wanneer je nu naar deze site browsed zal deze je meteen doorlinken naar de juiste CAS server (mochten er meerdere CAS servers zijn in de site, zal hij er random 1 kiezen).

Mocht je problemen hebben, wijzig in default.aspx.cs de variabele bolDebug naar True om te zien wat het response is van de Autodiscover service.
public bool bolDebug = true;

Zoals ik al aangaf is dit quick en dirty, dus mocht je verbeteringen hebben, laat het me weten.

Exchange 2007 bij Microsoft

mpriem — Wed, 12 Dec 2007 18:32:00 GMT

Altijd al willen weten hoe bij Microsoft de Exchange omgeving erbij staat. Dat kan nu... Een projectsamenvatting is HIER te vinden...

Nog een reden waarom Public folders mogen verdwijnen.....

mpriem — Fri, 07 Dec 2007 18:27:00 GMT

Naast het feit dat ik een mailsysteem geen plek vind om informatie met elkaar te delen, ben ik deze week achter nog een reden gekomen waarom public folders uit Exchange 2007 moeten verdwijnen. Dit heeft alles te maken met een probleem waar ik een maand mee bezig ben geweest...

Vorige maand is de klant waar ik momenteel voor werk een Exchange 2007 pilot gestart in een redelijk grote bestaande Exchange 2003 organisatie. Deze omgeving telt 100+ servers verspreid over 4 continenten. Daarbinnen hebben ze 52 Public Folder stores.

De initiele pilot groep telde +- 30 gebruikers, welke in UAT uitgebreid zou gaan worden naar +- 250 gebruikers. Vanaf het begin af aan kreeg ik klachten dat geheel willekeurig een Outlook client ineens bleef hangen voor 1 a 2 minuten, waarbij "retrieving data" popups verschenen, welke verwezen naar de 2007 public folder server die opgetuigd was voor de pilot users. Na verschillende perfmon sessies te hebben gedraaid op deze server, kon ik geen performance issues vinden. De hardware functioneerde prima, en ook de lokale GC's lieten geen problemen zien. Wel zagen we om het half uur hoge "RPC average latency" pieken. Na ook met network monitor aan de slag te zijn gegaan konden we zien dat de server elk half uur een waslijst aan Exchange servers verspreid over het hele forest aan het benaderen waren. We konden alleen zien dat het NetLogon verkeer was, aangezien de content encrypted is.

Microsoft werd erbij gehaald, maar na een week ploeteren hadden we nog geen inzicht in wat het probleem nou precies was. We hadden in de tussentijd al van alles gedaan. IsInteg gedraaid, andere public folder stores geprobeert. Aangezien de problemen zo willekeurig optraden konden we niet goed zien wat er nu precies gaande was. Het leek erop dat het probleem vaak optrad bij het opstarten van Outlook. Echter waren er ook berichten dat het ook gebeurde als iemand andere zaken aan het doen was of zelfs helemaal niets aan het doen was. In een poging het probleem in de kraag te vatten had ik Netmon op mijn werkstation weten te krijgen (is gesloten omgeving dus was een hele klus om toestemming te krijgen). Door via script Outlook om de 7 seconden te openen en te sluiten, hoopte ik te kunnen tracen wat Outlook nou precies vraagt, waar Exchange nu zo'n moeite mee heeft. na 3 uur had ik beet. Na de capture opgestuurt te hebben naar Microsoft (zij kunnen namelijk delen van RPC pakketjes decrypten), bleek dat het om een request te gaan waarbij Outlook vroeg op content van de "Outlook Security Forms". Om er zeker van te zijn moesten we proberen nog een packet te capturen, maar tegelijkertijd ook een perfmon en netmon sessie op de server te starten.

Dit bleek lastig aangezien we al moeite hadden het te triggeren met script. Op mijn werkstation was het al meer dan een week niet "zomaar" voorgekomen. Na intern overleg had ik toestemming op nog een aantal werkstations netmon te installeren. Echter bleek dit niet nodig te zijn, want na ik wat beter naar de netmon capture van de server te kijken en naar de perfmon sessie, kon ik een patroon vinden waarbij er telkens om het half uur een RPC request gedaan werd, waarna Exchange al die PF servers afging. Nadat dat klaar was, kwam er een RPC response, en precies op dat moment schoot de RPC average latency omhoog. Microsoft vroeg mij verschillende malen memorydumps te maken van store.exe. Tijdens de rpc peak, vlak voor de rpc peak etc etc. In totaal hebben we 15 GB aan dumps op moeten sturen. In de tussentijd was er een CPR engineer onsite geweest omdat MS zelf ook niet wist wat er nu precies gaande was. Veel meer dan meekijken kon hij niet. Kreeg meer de indruk dat hij kwam kijken of we de boel niet voor de gek aan het houden waren.
Enfin, Na een paar dagen was Microsoft klaar met het analyseren van de memory dumps en wat bleek. Het probleem werd veroorzaakt doordat Outlook de Public Folder hierarchy wilde laten reloaden. Dit kwam doordat er public folder stores in de hierarchy zaten die niet meer bestonden. Dit kan komen doordat public folder stores voor Exchange 2003 sp2 gewoon verwijdert konden worden, zonder de replicas te verplaatsen naar andere servers. Nu had ik in die omgeving al een keer een schoningsactie gehouden waarbij System folders van oude stores verwijdert waren en de replicalijst aardig schoon was (replstate test van ISINTEG schoont deze op). Echter het blijkt dat de replicalijst ook nog op andere plaatsen in de PF store opgeslagen wordt. Deze "orphaned" entries op die plek kunnen dus niet verwijdert worden en zorgen ervoor dat ze blijven voorkomen in de hierarchie. Outlook ziet de guids van deze nietbestaande PF stores en zal elke keer wanneer het de hierachie opvraagt vragen om een reload. Nu doet Exchange dit standaard 1 keer per uur, maar op aanvraag doet Exchange dat dus sneller, als er maar minimaal een half uur tussen zit.... Laat dat nu net de interval zijn dat we die high latency pieken zien.

Wat blijkt nu? In Exchange 2003 hadden we dat probleem dus ook, maar hadden we geen Outlook clients die hingen. Dat komt omdat de reload van Exchange 2003 veel sneller ging. In Exchange 2003 gebruiken we routinggroup connectoren met costs. Door een paar snelle AD queries kan Exchange dus heel snel de hierarchie opbouwen.
In Exchange 2007 gebruiken we echter AD sites met costs. Echter op een serverobject in AD staat niet in welke AD-site deze zit. Exchange moet dat dus zien te bepalen. En waar hebben de programmeurs voor gekozen??? ...Precies... Een sessie opzetten met de server om zo de site te achterhalen. Vandaar dat we de Netlogons zagen. En servers in Azie en Australie reageren nu eenmaal niet zo snel als ze achter high latency lijntjes zitten. Dus om het half uur wachtte een client totdat Exchange sessies had opgezet naar 52 PF server in de organisatie.

Hoe nu verder? Nou... Niet met Exchange 2007 public folders dus voorlopig. Als het aantal is teruggebracht van 53 naar 8, dan kunnen we erover denken, maar nu niet.
Er is wel de mogelijkheid om het interval van reloaden aan te passen. Dit doe je door een DWORD aan te maken in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsExchangeIS\\Public-(guid)

Dit DWORD moet heten "Replication Reload TLH Min" en de waarde is het aantal seconden die minimaal moeten zijn verstreken sinds de laatste reload. De maximale waarde is 43200 decimaal (12 uur). Zo kan je ervoor zorgen dat het probleem slechts 1 keer per 12 uur optreed. De enige echte structurele oplossing is om de hele PF tree opnieuw op te bouwen. Dat is echt heel erg lastig in grote omgevingen.

Omdat de programmeurs niet echt handig zijn omgesprongen met het reloaden van de hierarchie in Exchange 2007 is dit probleem nog in onderzoek bij de productgroep. Hopelijk wordt er een aanpassing gemaakt. Misschien wordt dit zelfs als bug aangeduid. Hoe het ook wil, op dit moment zijn public folders in grote omgevingen dus RUK...

Van mij mogen ze verdwijnen.

Mailbox verhuizen met EMS & EMC

mpriem — Thu, 29 Nov 2007 18:26:00 GMT

Mailboxen verhuizen is een van die taken die geregeld gedaan worden binnen een Exchange organisatie, maar hoe werkt het precies in Exchange 2007?

In tegenstelling tot Exchange 2003 hebben we nu de mogelijkheid om naast de GUI ook gebruik te maken van een commandline interface, in de vorm van het Move-Mailbox cmdlet. Dit stelt ons in staat op basis van filters source en destination te bepalen. Een leuk voorbeeld is het volgende:

$db = (Get-ExchangeServer | get-MailboxStatistics | Sort-Object Count | Select-Object Name)[0] Get-User | ?{$_.City -eq "Zoetermeer"} | Move-Mailbox -TargetDatabase $db

Deze regels code verplaatsen alle mailboxen van gebruikers uit Zoetermeer naar de database met de minste mailboxen.

Naast de toevoeging van de shell heeft de move mailbox wizzard in de console een opknapbeurt gekregen. Het schijnt ook dat de achterliggende code beter geintegreerd is met de servercode, dus laten we dat maar aannemen. Wat in ieder geval wel aantoonbaar gewijzigd is zijn de pre-move checks. Voordat een mailbox verhuist wordt werden zaken als rechten en het mailboxtype (wel of geen system mailbox) in Exchange 2000+ ook al gechecked. Wat er nu ook nog gechecked wordt is of de properties van de mailbox ook nog kloppen. Dit zijn checks waar ik eerder ook al aandacht aan heb besteed. De methode Validate() op het mailboxobject wordt aangeroepen en checkt of bijv. de alias geen spaties bevat en of het mail attribute hetzelfde is als het primary proxy address. Voldoet de mailbox niet, vindt er geen move plaats.
Voldoet hij wel, wordt er een MAPI sessie opgezet naar zowel de source als de destination server. De source mailbox wordt getagged met een PR_IN_TRANSIT flag, waarna op de destination server de nieuwe mailbox aangemaakt wordt, ook getagged met de PR_IN_TRANSIT tag. De PR_IN_TRANSIT flag zorgt ervoor dat de mailbox in een soort read-only status terecht komt, wat clients en Exchange weerhoudt wijzigingen te maken op de mailbox. Client wijzigingen worden in het geheugen gemaakt en nieuwe email wordt gequeued. De move vindt plaats door de mailbox als 1 stream te verplaatsen. Tijdens de move worden MAPI berichten gecontroleerd op corruptie en een counter bijgehouden. Het move-process zal proberen corrupte items te repareren, maar zal nooit een corrupt item opslaan in de target mailbox. Vandaar dat het moven van een mailbox dus soms problemen met rules en dergelijke op kan lossen. Of een item wel of niet corrupt is wordt bepaald door de aanwezige MAPI attributen op het bericht te controleren. Voor een move kan je zelf aangeven hoeveel items maximaal corrupt mogen zijn. Als deze waarde overschreden wordt, zal de move ongedaan worden gemaakt. Als de mailbox eenmaal over is, worden de msExchHomeServerName, HomeMDB en HomeMTA properties aangepast op het user object. Het is aan te bevelen de wijzigingen te laten uitvoeren op een GC in de site waar de target Exchange server zich bevindt. De source Exchange server weet van de move en zal MAPI connecties voor de betreffende mailbox doorzetten naar de target Exchange server. Deze zal in AD controleren of de MAPI connectie voor hem bestemt is. Op deze manier zouden mailbox moves bijna seamless moeten zijn. Je kan door blijven werken met Outlook. Het kan echter zijn dat de Outlook vraagt de client te herstarten. Dit is meestal wanneer de client ook doorverwezen wordt naar een nieuwe default Public folder store.
Nu dat de mailbox over is en de AD attributen zijn aangepast zal de source server de mailbox verwijderen en de target server de PR_IN_TRANSIT flag van de mailbox halen. De move is nu voltooit.

Exchange 2007 SP1 coming to a server near you!

mpriem — Thu, 29 Nov 2007 18:25:00 GMT

Het is dan eindelijk zover... SP1 is vanaf morgen hier vrij verkrijgbaar.

De hightlights voor deze aanvulling zijn:

Ondersteuning voor Windows Server 2008
Uitgebreide ActiveSync policies
High availability opties als "Standby Continuous Replication" en cross-site resilience.
Uitbreiding op GUI voor bijvoorbeeld Public Folders en connector configuratie.

Helaas hebben we voor dit servicepack een schema uitbreiding nodig.

Enjoy!