Error c1030af7 al desplegar les carpetes públiques

En l’Exchange 2003 ens trobem l’error c1030af7 al desplegar les carpetes públiques.

 El error que apareix és “Error en la operación. Error HTTP 501 (No implementado)”

Revisant els documents de Microsoft, veiem que pot ser per diverses causes, però la més probable és que el IIS no tingui el Default Web Site en el port 80 o 443.

 En un servidor Exchange el IIS ha de tenir el Default Web Site en el port 80/443. No hi ha més. Ha de ser així.

 Si ho tenim així, aleshores pot haver-hi algún problema amb la metabase del IIS, o bé amb el director ExAdmin creat al Default Web site. Podem recrearlo amb l’script

cscript adsutil.vbs delete ds2mb

Reiniciant el System Attendant es recrea una altra vegada la informació.

El millor que es pot fer es consultar l’article on es mostren tots els errors que poden apareixer al desplegar les carpetes públiques:

Troubleshooting Microsoft Exchange System Manager Public Folder Expansion Problems

GreyListing – Problema amb l’exchange 2003

A vegades trobem missatges a la cua del SMTP que no han estat entregats, i que tampoc han reportat cap NDR a l’usuari que el va enviar.

Això és degut a un problema de l’exchange 2003 SP2 amb el GreyListing.

El Greylisting és una implementació que s’està estenent a tots els productes de correu i filtre d’spam que permet filtrar el correu SPAM segons l’origen, sense haver-lo de comparar amb cap llista BlackList ni buscar a una llista de RBL.

El mecanisme del GreyListing és molt senzill. Quan arriba un correu, el servidor obté la IP Origen, el destinatari i l’adreça origen del missatge.

Si és la primera vegada que veu aquesta tripleta, denega la connexió amb un codi SMTP 451 (reintentar més tard). Aleshores el servidor origen al rebre aquesta resposta, posa el missatge a la cua i ho torna a intentar més tard. Si el “servidor” és un Spammer, el més probable és que no ho torni a reintentar, i ens estalviem el correu SPAM.

Fins aquí tot sembla correcte.

El problema és que Exchange 2003 no sap interpretar correctament aquest missatge SMTP 451, i a vegades (no sempre), deixa el missatge en un estat “catatònic”, sense enviar NDR a l’usuari ni reenviar novament el missatge.

Aquest comportament està definit al categoritzador avançat SMTP (SMTP Advanced Queuing Engine). Per defecte, quan arriba un missatge 400 d’un servidor SMTP, el que fa es reintentar durant un timeout especificat a GlitchRetrySeconds al registre (normalment 60 segons) durant dues vegades més. Si falla 3 vegades, aleshores ho posa al final de la cua SMTP per tornar-ho a reintentar, i per no aturar la resta de la cua.
El problema és que aquest temps de Glitch és massa curt, i aleshores el missatge és queda en un d’aquests 3 reintents, sense passar al cua novament, i sense avisar a l’usuari.

Hi ha diverses solucions a aquest problema. Una d’elles es aturar i arrencar el servei SMTP del servidor. Per fer això podem fer un script que cada dia ho faci. Fem un net start smtpsvr && net stop smtpsvc en una tarea programada, i obtenim aquest reinici programat.

L’altre sistema és esperar que Microsoft tregui un pedaç.

També podem incrementar el temps de GlitchRetrySeconds a 120 segons, i sembla que el problema desapareix.

Quan aparegui l’article solucionant el problema, el penjaré aquí.

Sembla que PSS de Microsoft ja té algun pedaç que proporciona a qui truca solicitant suport, però encara no tinc les dades.

Guia d’optimització de memòria de Exchange 2003

Aquí publico un link amb les opcions de configuració de memòria recomanades per Exchange 2003:

How to optimize memory usage in Exchange Server 2003

 Aquestes opcions també apareixen a l’Exchange Best Practices Analyzer Tool, descarregable aqui:

Microsoft Exchange Best Practices Analyzer v2.8

PSTs sobre enllaços de xarxa (PST over network links)

Un escenari típic en les empreses és disposar d’un client Outlook per l’accés al correu. Aquest sistema de correu que acostuma a ser POP3 o bé d’un servidor Exchange, guarda les seves dades en un arxiu .PST.

 El que trobem habitualment és que aquest arxiu PST està ubicat en una unitat de xarxa, per poder facilitar la mobilitat d’aquest usuari, o bé evitar que es perdin les dades en cas de problemes amb el disc dur del PC client.

 Doncs sorpresa: Aquesta és una configuració NO suportada per Microsoft. Les alternatives de Microsoft són dues: utilitzar el servidor Exchange i els arxius OST, o bé fer servir Terminal Server o Citrix.

 Perquè? Doncs us intentaré donar alguns exemples:

EXEMPLE 1:

Empresa amb 100 usuaris que disposen cadascun d’ells d’un o dos arxius PST d’1 Gb (no és estrany trobar-se bústies de 1Gb avui en dia)

Cada matí, a les 8 del matí,  100 usuaris accedeixen a uns 100-150 arxius d’1Gb a la vegada. Això és molt de trànsit puntual al servidor. Això fa que els usuaris notin un redard a l’obrir el Outlook, hi hagin queixes, etc.

El servidor a primera hora es queda sense donar practicament servei, apareixen errors event id 2021 i event id 2022, etc. Els administradors no saben què passa, però veuen com els recursos baixen, i la resta de serveis de xarxa que proporciona aquest servidor es veuen clarament afectats.

A més, aquest no és un problema fixat, ja que la mida dels arxius PST cada vegada s’incrementa més i més, ja que els usuaris MAI borren el seu correu, tal i com se’ls demana.

EXEMPLE 2:

Empresa de 500 usuaris que cada cert temps s’envia notes informatives a tots els usuaris via correu. Automàticament els 500 arxius PST són modificats a l’hora. El servidor no pot absorvir tanta demanda de I/O. Els usuaris veuen com el seu Outlook deixa de funcionar. Els administradors no saben què passa, però el servidor deixa de respondre amb un I/O molt alt. Fallen els recursos disponibles. Baixen a zero els Available Work Items, apareixen errors event id 2019, 2020, 2021, etc.

 Durant uns minuts, el servidor no dóna servei a ningú. Tots els usuaris es veuen afectats.

Solució:

 La solució passar per posar un servidor Microsoft Exchange Server. També pot solucionar-se amb accés a través de Terminal Server al Outlook, o solucions de WebMail.

 La recomanada per mi: Posar un servidor Exchange i utilitzar els arxius .OST del outlook (el mode cache)

 Aquí teniu un link que mostra la versió oficial de Microsoft al problema:

Personal folder files are unsupported over a LAN or over a WAN link

Com habilitar el Exchange Writer del SBS 2003

Per defecte el Exchange Writer del Volume Shadow Copies del Windows 2003 està deshabilitat.

Això és així perquè el backup del SBS no presenti problemes amb el NTBackup.

En canvi, si volem usar una eina de tercers per realitzar el backup, aleshores no podem fer a la vegada el backup del System State i de l’Exchange.

Per tal de resoldre el problema, cal habilitar des del registre el Exchange Writer (i reiniciar el servidor, clar):

Anem a
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ MSExchangeIS\ParametersSystem

i deixem el Disable Exchange Writer a 0 (zero)

Ho podem trobar reportat aquí

El filtre antispam IMF no funciona amb el connector POP3 de Small Business

El filtre IMF incorporat en la versió Exchange 2003 Service Pack 1 i millorat en la versió Service Pack 2, no funciona amb els correus que provenen del conector POP3 que incorpora Small Business.

Això és així perquè el correu que prové de la carpeta pickup (on va a parar el correu POP3), no provoca l’event sink “End of Data”, i per tant no es revisat pel IMF.

Podem veure un FAQ sobre aquest tema aquí

Recomanacions per la configuració del RAID

Les meves recomanacions a l’hora de crear un RAID són:

• No posar MAI un RAID 5. La tecnologia de RAID 5 es molt lenta en escriptura, penalitzant qualsevol tipus de BBDD. S’ha d’utilitzar en l’últim cas, mai en una configuració inicial.
• Revisar que la controladora RAID tingui bateria per poder activar la caché d’escriptura. En el servidors HP Proliant, la bateria BBWC (Battery Backed Write Cache) no ve  per defecte i si no està disponible no pots activar la caché d’escriptura per Hardware. Tot i que només val uns 100€, la perdúa de rendiment es molt gran. Es probable que un PC normalet amb un disc IDE/ATA (que porten inclosa una cache de 8Mb) sigui més ràpid que un servidor sense cache d’escriptura.
• Posar sempre el màxim de discs petits, millor que pocs discs més grans
• Especificar sempre RAID 0+1, o 1+0, o 10 (segons el fabricant, ja que no hi ha un estandard), millor que RAID 1 a seques. Un RAID 1 de dos discs generalment és un simple mirror, i el rendiment no millora, ja que es treballa amb un disc i la controladora actualitza l’altre. En canvi RAID 0+1 parteix els dos discs, i quan ha de gravar dades, grava la meitat a cada disc, per tant, triga justament la meitat.
• Separar els tipus d’accés diferents en discs físics (o volums) diferents. En les BBDD transaccionals (Exchange, SQL server, Oracle, etc) veiem que els arxius de dades es divideixen en dues parts. El arxiu on estan les dades propiament i l’arxiu o arxius on estan els logs (o redo logs). Mentre l’arxiu de les dades té un accés aleatori (es pot anar a llegir o escriure a qualsevol part de l’arxiu), els logs sempre són seqüencials. Per tant, si tenim un volum només amb les dades seqüencials, la lectura avançada de la caché será més útil, i el rendiment millorará.
• Separar SEMPRE les unitats de disc de les unitats de Cinta. Mai s’han de barrejar en un mateix bus SCSI una unitat de Cinta i un array de discs. Això provocará que els discs vagin a la velocitat de les cintes.
• Mai punxar discs de diferent versió de SCSI al mateix bus. Si tenim discs Ultra2, Ultra160 o Ultra320 i els posem junts, tots aniran a Ultra2.
• El mateix passa amb les revolucions. Juntar discs de 10K amb discs de 15K fa que tots vagin al rendiment del més lent.
• Cal anar en compte amb les cabines de disc. Algunes cabines de disc han quedat obsoletes, i tot i que externament es connecten a 2 Gbps (o a 4 Gbps), i fins i tot acceptin discs Ultra320, pot ser perfectament que el bus intern només funcioni amb tecnologia Ultra2, baixant tot el rendiment del sistema a Ultra2.
• Afegir discs SATA per realitzar el backup. Els discs SATA de 500 Gb tenen un cost molt més baix que els discs SCSI, i permeten realitzar un primer backup a disc que es fará en minuts. Després aquest backup es pot passar a Cinta, per poder endur-nos les dades fora del CPD Principal.

Two core RAID levels are of value for a database server: striping with parity (RAID 5) and striped mirror (RAID 0+1). The best overall option is to choose RAID 0+1 (also called RAID 01 or “striped mirror”). RAID 5 can be used in certain circumstances, but is generally more expensive in the long run, and less reliable.

Totes aquestes recomanacions es poden trobar en aquests links:

 Best Practices Common to Multiple Architectures

SQL Server 2000 Operations Guide: Capacity and Storage Management

Problemes amb la caché de Outlook (memòria cau)

Després d’una migració exitosa, es pot donar el cas que alguns usuaris tinguin problemes per enviar correu.

Quan envien a algú de la mateixa organització, els hi retorna un NDR (non-delivery report) del tipus 5xx:

De Palomo, Juan en 28/02/2007 10:34
The message could not be delivered because the recipient’s destination email system is unknown or invalid. Please check the address and try again, or contact your system administrator to verify connectivity to the email system of the recipient.

Això pot ser degut a la caché del outlook (memòria cau en endavant).

Quan l’usuari tecleja les primeres lletres del nom a qui vol enviar el correu, automàticament apareixen proposades les adreces dels usuaris. Aquestes adreces no estan extretes de la Global Address List, sinó que resideixen en un arxiu acabat en .nk2 situat en el perfil de l’usuari.

Per tal de regenerar aquesta memòria cau, cal seguir el següent procediment (bàsicament borrar l’arxiu, depenent de la versió del Outlook de que disposem):

How to reset the nickname and the automatic completion caches in Outlook

Recuperació Dial-Tone d’Exchange 2003

Ja m’ha tocat fer una recuperació Dial-Tone.

Ha funcionat, com preveu Microsoft a la seva documentació.

Per qui no sàpiga què és això del Dial-Tone, es tracta de posar en producció un servidor Exchange caigut en segons. La BBDD està en blanc, però els usuaris poden tornar a rebre i enviar correus de manera immediata.

En 1 minut la BBDD s’ha aixecat, i els usuaris han pogut rebre i enviar correu sense problemes.

Els pàssos bàsics del procés són:

1) Resetejar la BBDD actual. És a dir, moure tots els arxius del MDBDATA a un altre carpeta, i deixar la carpeta MDBDATA en blanc.
2) Iniciar el Storage Group. Muntar les BBDD. Al fer això, es recrea una estructura nova de carpetes. Les bústies estan en blanc. Els usuaris no poden veure els seus correus antics, pero poden treballar.
3) Enviar un mail a tothom avisant que ja funciona el correu, però que no poden accedir als correus vells.
4) Aleshores cal començar la recuperació de la BBDD vella:
5) Cal crear un Recovery Storage Group. Creem un nou Recovery Storage Group que es digui igual que l’antic (el seleccionem de la busqueda que realitza l’assistent). NO MUNTAR!
6) Posar aquest recovery storage group com a sobreescribible per un backup, a les opcions del Storage Group.
7) Fer la restauració, o el ESEUTIL de la BBDD Vella fins que es pugui muntar. Un cop muntada, i quan el sistema ho permeti, hem de desmuntar els dos storage groups i canviar les ubicacions de la BBDD, deixant els arxius del recovery al lloc de la BBDD original, i la BBDD dial-tone, a la carpeta del recovery. Si fem la restauració, es farà per defecte sobre el recovery group, no cal especificar cap opció en el software de backup (Veritas en aquest cas)
Un cop muntades les BBDD, tenim dues opcions, depenent de si tenim instal·lat el Service Pack 1 d’Exchange 2003 o no. A partir del service pack 1, apareix una opció en les bústies del Recovery Storage Group que permet obrir l’assistent de copia de dades.
L’altra opció es fer-ho amb el ExMerge, però és més complicada, i acostuma a donar errors. Es pot veure una llista dels errors més comuns aqui: Troubleshooting ExMerge Issues

El que ens va afectar a nosaltres durant l’Exmerge va ser la localització del nom “Almacén …”, ja que no el trobava. Per això vam anar al exmerge.ini (que cal copiar a la carpeta bin del Exchange) i vam modificar el atribut LocalisedExchangeServerServiceName, treient el ; de davant de la opció spanish. El procediment es troba aquí: How to Discover and Configure the Correct Names for MAPI Services

Aquí podem trobar informació de les tasques que es relacionen més amunt:

Creació i configuració de Recovery Storage Group:
Recovering a Mailbox Database Using a Dial Tone Database in Exchange Server 2003

Introduction to Using Exchange Server 2003 Recovery Storage Groups

Exchange Server 2003 SP1 Recover Mailbox Data Feature

IMPORTANT: Al recuperar la base de dades antiga, cal tornar a copiar els arxius en la seva localització original i tornar a aixecar la BBDD en el Storage Group Original. Si no es fa així, caldrà regenerar tots els arxius .OST del Outlook, ja que pensen que el mailbox es diferent.

Comprovació Logs Exchange 2003

A vegades algún software Antivirus o Antispam (o una simple caiguda del servidor per temes elèctrics) pot deixar en estat inconsistent la BBDD priv1.edb.

Trobarem que tot i que els serveis estan aixecats, els clients Outlook no poden connectar, i a l’entrar al System Manager veiem que el Information Store no esta muntat. (Evidentment a l’intentar muntar-lo falla)

Es pot revisar al visor d’events (event viewer), que probablement informa d’un error al MSExchangeIS, i probablement ens indiqui el nom de l’arxiu que falla (dirá que no el pot obrir per problemes de permisos, o el que sigui)

Per tal d’esbrinar en qui estat està la BBDD podem executar la comanda ESEUTIL /MH priv1.edb.

Aqui podrem veure quins logs són necessaris per la recuperacio de la BBDD, (a log required, només cal passar-los a hexadecimal i buscar el edb000xxxx.log corresponent, que estará a la carpeta MDBDATA).

També podem fer un recorregut per tots els logs per comprobar l’estat dels mateixos amb ESEUTIL /ML e00.

Aquesta instrucció ens mostra l’estat dels mateixos, especificant si estan bé i si els troba correctament:

D:\exchsrvr\MDBDATA\log3\test>eseutil /ml e00

Microsoft(R) Exchange Server Database Utilities

Version 6.5

Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

Initiating FILE DUMP mode…

Verifying log files…

Base name: e00

Log file: D:\exchsrvr\MDBDATA\log3\test\E0000001.log – OK

Log file: D:\exchsrvr\MDBDATA\log3\test\E0000002.log

ERROR: Log damaged (unusable). Last Lgpos: (0×2,1059,0). Error -501.

Log file: D:\exchsrvr\MDBDATA\log3\test\E0000003.log – OK

Log file: D:\exchsrvr\MDBDATA\log3\test\E0000004.log – OK

Log file: D:\exchsrvr\MDBDATA\log3\test\E0000005.log – OK

Log file: D:\exchsrvr\MDBDATA\log3\test\E0000006.log

ERROR: Invalid log sequence. Previous generation time is [12/27/2002 13:15:24], but expected [12/30/2002 17:03:33].

Log file: D:\exchsrvr\MDBDATA\log3\test\E0000007.log – OK

Log file: D:\exchsrvr\MDBDATA\log3\test\E0000008.log – OK

Tota aquesta informació es pot trobar en el següent article:

Cross-Matching Exchange Databases and Log Files