[exchange 2000] Servers kunnen onderling geen mail versturen

[Verwijderd]

oude situatie:
1 exchange server in ons forest die de mail afhandelt (Exchange 2000 met sp3+)

Nieuwe situatie
2 Exchange frontend servers die loadbalancen
4 backend servers die de public folders en de mailstores hosten
Allen win2k adv. server met laatste sp's en fixes en allen exchange 2000 met sp3 en eenerlaatste sp3 rollover package.
De 'oude' exchange server is nog actief en host op dit moment nog alle mailboxes en public folders.
Alle exchange servers zitten in dezelfde site en we maken dus geen gebruik van routing groups..(alle zitten in de default)


Sinds de nieuwe servers in het domein actief zijn krijgen we op de bestaande mailserver de volgende event meldingen:
Event Type: Warning
Event Source: MSExchangeMTA
Event Category: Security
Event ID: 9297
Date: 14-11-2003
Time: 14:28:51
User: N/A
Computer: XXX-XXX-XX
Description:
The user /o=XXXX XXXXXXX XXXXXXXXX/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=YYY-YYY-YY has caused a security violation. Locality table (LTAB) index: 134. Windows 2000 error code: 0X80070005. [BASE IL MAIN BASE 1 237] (14)

waarbij de YYY-YYY-YY in de event meldingen de namen van de nieuwe exchange servers zijn.
Bovendien kunnen op dit moment de public folders niet gerepliceerd worden naar de nieuwe servers en ook het versturen van mail naar mailboxen die op andere servers aanwezig zijn blijft in de queue staan (overigens wel in de juiste). Mail naar buiten wordt netjes afgeleverd bij onze mailgateway en mail vanaf buiten komt ook netjes overal aan....

Hierbij heb ik het volgende Knowledge base artikel gevonden:
http://support.microsoft.com/?kbid=288175

We hebben van de workaround de recipient policies aangepast zoda er geen @servernaam.domeinnaam.nl instaat. En verder hebben we natuurlijk nog veel geprobeerd maar helaas zonder resultaat.....
De meldingen komen nog steeds en ook mail blijft in de queues staan....
De huidige recipient policies zien er als volgt uit:
smtp: [e-mail]
SMTP: @domeinnaam.nl (deze is default)
X400: xxxxxx
De gebruiker hebben het automatic update vinkje uitstaan en hebben dus nog wel de @servernaam.domainnaam.nl bij de e-mail adressen staan waarbij de servernaam de naam van de server waarop hun mailbox zich bevind is....

We hebben dit probleem overigens in onze testomgeving niet gehad....zelfs als we het daar proberen te reproduceren lukt het niet...

Met andere woorden; als iemand nog suggesties heeft hoor ik het graag....

[reddog33hummer]

heb je onderling wel de goede certificaten bij alle servers ?

[Verwijderd]

We maken geen gebruik van certificaten dus lijkt me niet het probleem?

[mutsje]

heb je na het veranderen van je policy wel de policy update gedraait? in je Exchange system manager console? Anders gaat zo'n verandering erg lang duren ben ik bang.

en deze al geprobeerd?
247787
Dit is wel exchange5.0/5.5 maar misschien hint in de goede richting

[ Voor 39% gewijzigd door mutsje op 14-11-2003 16:51 ]

[Kabouterplop01]

Maak je gebruik van een/meerdere smarthost's?
gebruik je DNS resolving?
gebruik je een masquerade domain?
Staan je MX records goed?
Staat de file replication service aan?
Is er een trust met de OUde exchange server?
trust de OUde exchange server de nieuwe front/back-end?
Staat de AD ingesteld op mixed of native mode?
Wat voor een machine is de OUde? NT4/exch5.5 of ook exch2000?
gebruik je "externe" DNS om te resolven.

[Kabouterplop01]

Ik weet nog steeds niet te editten

Oh ja gebruik je een SMTP connector??

[Verwijderd]

@mutsje:
Ik ga het document uitprinten....
Ik had dit inderdaad ook al gevonden, en ik zou er graag iets mee doen, alleen ik weet niet zo goed wat er in exchange 2000 mee moet.... of te wel waar en is dit eigenlijk wel te vinden in exchange 2000

Kabouterplop01 schreef op 14 november 2003 @ 16:59:
Maak je gebruik van een/meerdere smarthost's?
- ja 1 smarthost
gebruik je DNS resolving?
- kan niet anders he??
gebruik je een masquerade domain?
- ja
Staan je MX records goed?
- ja, daar ga ik wel vanuit
Staat de file replication service aan?
- Nee, maar heeft exchange dat dan nodig??
Is er een trust met de OUde exchange server?
- Nee zelfde domein
trust de OUde exchange server de nieuwe front/back-end?
- Zelfde domein
Staat de AD ingesteld op mixed of native mode?
- AD is native exchange ook
Wat voor een machine is de OUde? NT4/exch5.5 of ook exch2000?
- deze is Exch 2000
gebruik je "externe" DNS om te resolven.
- Voor buitenwereld wel

We gebruiken geen SMTP connector

[ Voor 24% gewijzigd door Verwijderd op 14-11-2003 17:26 ]

[Kabouterplop01]

DNS resolving: Logisch maar ik bedoelde DNS resolving of smarthost, sorry mijn onduidelijkheid.
File replication/site replication is wel nodig ja. De policies moeten toch geupdate worden. De Global Catalog moet worden geraadpleegd.... En ALS de cluster OF de OUde bak zelf Global Catalog zijn moet dat repliceren wel kunnen!

Mag de cluster "schrijven" op de OUde bak?

[Verwijderd]

Kabouterplop01 schreef op 14 november 2003 @ 17:52:
DNS resolving: Logisch maar ik bedoelde DNS resolving of smarthost, sorry mijn onduidelijkheid.
File replication/site replication is wel nodig ja. De policies moeten toch geupdate worden. De Global Catalog moet worden geraadpleegd.... En ALS de cluster OF de OUde bak zelf Global Catalog zijn moet dat repliceren wel kunnen!

Mag de cluster "schrijven" op de OUde bak?

Voor de externe mail gebruiken we de smarthost en voor de interne mail de DNS resolving.
Ik heb de file replication service aangezet, maar ik snap niet wat je hiermee wilt bereiken??? Geen van de Exchange servers is domain controller (of global catalog)...... De replicatie van het domein is verder in orde!

Het cluster? Het is geen cluster...of ja de frontends zijn een loadbalancing cluster....Wat bedoel je precies met schrijven op de oude bak?

[Kabouterplop01]

OK.
Het lijkt er op dat de cluster iets probeert waardoor NT/AUTHORITY een security melding geeft.
Ik heb zelf thuis getest met exc2000 en 2003 frontend (maar 2 machines).
En toen heb ik meen ik expliciet de machines "rechten" gegeven middels NTFS om bij elkaar te mogen schrijven.(properties>>>security en dan het obj modify geven)
Misschien past het helemaal niet in je security model o.i.d. maar toen werkte het bij mij. Vandaar de vraag m.b.t. repliceren van zowel AD alsmede de site replication(echter zit alles in dezelfde site). Als de ene server iets stuurt maar de andere "mag" het niet verwerken, krijg je zo'n melding.
Misschien zitten we wel in de verkeerde hoek, maar we moeten ergens beginnen

[Kabouterplop01]

[e-mail] =DNS>>MX record De mail wordt steeds afgeleverd en verstuurd met de zelfde bak.
Het lijkt erop dat de recipients geforced worden van een bepaalde machine gebruik te maken.
Wel link om aan te passen zo'n cluster en front-backend = VEEEEEL MEEEEL.
Ik zou de MX preference naar de cluster laten wijzen
dus zoiets:
cluster.domein.nl=5
oude exch.domein.nl=10
Je krijgt dan wel veel intern geschuif ineens.+inkomend+uitgaand=VEEEEL MEEEL

[Brahiewahiewa]

Als je nou gewoon effe op www.eventid.net zoekt, dan vind je: "There seems to be a problem when a recipient policy contains the Fully Qualified Domain Name (FQDN) of an Exchange Server. Q288175 suggests either to rename the reference to the FQDN inside the policy or to rename the server (which obviously is not too preferrable)."
Na een keuze te hebben gemaakt tussen een van deze twee oplossingen, is je error nog steeds niet weg: "We discovered that Exchange - at least sometimes - tries to deliver the concerned mail via X.400 instead of STMP, causing the mail to stay in the X.400 queue and producing this error every 10 minutes. Deleting the mail from the queue should stop the error messages."

[ Voor 3% gewijzigd door Brahiewahiewa op 15-11-2003 10:01 ]

[Verwijderd]

@ Kabouterplop01

Thx voor de info, ik ga het meteen proberen, ik heb inderdaad het idee dat het in die richting zit. Eens kijken hoever we komen, ik hou je op de hoogte....
Ik ga eerst eens naar die rechten kijken...


@ Brahiewahiewa

In de startpost heb ik al aangegeven dat ik dit al gevonden had, maar dat dit artikel en de daarin genoemde workarounds ons niet tot het gewenste resultaat hebben gebracht...

[Brahiewahiewa]

Verwijderd schreef op 15 november 2003 @ 20:27:
@ Brahiewahiewa

In de startpost heb ik al aangegeven dat ik dit al gevonden had, maar dat dit artikel en de daarin genoemde workarounds ons niet tot het gewenste resultaat hebben gebracht...

Dat zeg ik! Maar je moet dus die queues zelf leeggooien; zolang je dat niet doet, blijft de foutmelding terugkomen

[Verwijderd]

Brahiewahiewa schreef op 16 november 2003 @ 11:08:
[...]

Dat zeg ik! Maar je moet dus die queues zelf leeggooien; zolang je dat niet doet, blijft de foutmelding terugkomen

De queus zijn daana leeggegooid, helaas zonder resultaat de foutmelding blijft komen en de exchange server kunnen onderling nog steeds niet mailen....

[Brahiewahiewa]

Verwijderd schreef op 14 november 2003 @ 15:10:
[...]De gebruiker hebben het automatic update vinkje uitstaan en hebben dus nog wel de @servernaam.domainnaam.nl bij de e-mail adressen staan waarbij de servernaam de naam van de server waarop hun mailbox zich bevind is....

Dan zal het toch wel aan die <user>@servernaam.domain.naam.nl liggen. Is het te doen om die vinkjes aan te zetten en te wachten tot de RUS z'n werk heeft gedaan?

[Verwijderd]

Brahiewahiewa schreef op 16 november 2003 @ 14:00:
[...]

Dan zal het toch wel aan die <user>@servernaam.domain.naam.nl liggen. Is het te doen om die vinkjes aan te zetten en te wachten tot de RUS z'n werk heeft gedaan?

Ik heb bij een aantal gebruikers de @servernaam.domain.naam.nl weggehaald, maar ook nu blijft de mail gewoon in de queue staan. Natuurlijk queues weer leeggegooid...
Qua rechten lijkt verder alles goed te staan......

[ Voor 6% gewijzigd door Verwijderd op 17-11-2003 11:58 ]

[Kabouterplop01]

Wat zijn de ILS settings bij active dir. advanced exchange?
Staat daar toevallig dezelfde gebruikersnaam (<user>@domein.nl)
bij de oude exchange machine?

[Brahiewahiewa]

Je kunt wegkomen met recipient policies die hetzelfde zijn als servernamen, onder voorwaarde dat de mailboxen in kwestie op die bewuste server gehost worden.

Je maakt dan een recipient policy voor <user>@server.domain.nl en gaat dan - met ADSIedit of je eigen favoriet LDAP editor - naar de properties van van die recipient policy.

Daar zoek je het attribuut msExchAppliesToSmtpVS en dat vul je met de DN van de virtuele SMTP server (CN=1,CN=SMTP,CN=Protocols,CN=<Server>,CN=Servers,CN=<Administative Group>,CN=<Organization>,CN=Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<nl>) en dan zorg je ervoor dat het filter op de recipient policy alleen mailboxen op die server toelaat.

[Verwijderd]

@Kabouterplop01
Ik neem aan dat je de ILS settings bij de gebruikers bedoelt, die zijn blank zowel bij de oude als de nieuwe exchange servers.


@Brahiewahiewa
Ik ga morgen eens uitproberen hoe dat precies zit bij ons. Ik heb wel al iets soortgelijks geprobeerd:
voor elke server een eigen recipent policy (dmv filter rules) waarin dan [e-mail] staat. Helaas ook dit was zonder resultaat. Ik zal morgen eens naar dat stukje van jou kijken.
Thx alvast

[Kabouterplop01]

Ik heb denk ik iets gevonden.
http://support.microsoft....px?scid=kb;EN-US;315591op MS knowledgebase.
en
http://support.microsoft....aspx?scid=kb;EN-US;321721

[Verwijderd]

Update:
Het probleem bleek toch niet gerelateerd met de security violation meldingen te zijn.....
Wat was nu wel het probleem:
We hebben op alle virtual smtp servers onze smarthost gedefinieerd. Dit was dus hetp probleem in combinatie met de recipient polcies. Nu kun je daar het volgende vinkje aanzetten:

Attempt direct delivery before sending to smart host
Use this check box to first attempt to send e-mail messages directly to the recipient before relaying them through the smart host. Many administrators use this feature to send internal e-mail directly, and use the smart host for Internet e-mail.

Als ik dit aanzet kan ik zowel interne als externe mail versturen. Alleen, nu gaat zowel de interne als de externe mail rechtreeks naar buiten. En dat willen we niet. De interne mail MOET rechtstreeks gaan, de externe mail (dus mail naar buiten) MOET via de mailgateway gaan.

Waar we ook nog tegen aanlopen is het volgende:
onze mailgateway (unix) is baas van xxxxxx.nl
in de AD hebben we een domein yyyy.xxxxxx.nl-> Exchange is via de recipient policy verantwoordelijk voor alle mail binnen dit domain.
Verder hebben we nog een hoop lostaande domeinen die ook eindigen op xxxxx.nl

MOeten we nu met smtp connectors gaan werken, de recipient polices aanpassen en naar wat?.....of iets anders...wat zien we over het hoofd hier.

[Kabouterplop01]

Ik denk dat dat moet worden aangepast in DNS. De mail naar buiten moet via DNS
En de interne mail dus niet via de smarthost.
Zie ook de link die ik stuurde. En een SMTP connector is dan denk ik wel handig. Je wilt toch naar buiten via de mailgateway. SMTP preferred bridgehead??
Of.... Maar dat is denk ik te, op de cluster outbound mail disabelen.

[Verwijderd]

Ke heb DNS aangepast, MX records gemaakt die voor het AD domein naar de Exchange servers wijzen. Verder heb ik 2 smtp connectors aangemaakt 1 die @yyyy.xxxx.nl (ad domain naam) direct locaal aflevert en 1 die * aflevert bij de smarthost. Nu werkt het interne deel, maar de externe komt niet van exchange af. Krijg een onbezorgbaar:
Uw bericht heeft enkele of alle geadresseerden niet bereikt.

Onderwerp: test
Verzonden: 20-11-2003 14:51

De volgende geadresseerde(n) zijn niet bereikt:

[e-mail] op 20-11-2003 14:51
Het e-mailadres kan niet worden gevonden. Het is mogelijk dat de geadresseerde inmiddels is overgestapt naar een andere e-mailorganisatie, of dat het adres een fout bevat. Controleer het adres en probeer het nogmaals.
<srv-tst-31.yyy.xxx.nl #5.1.8 smtp;553 5.1.8 <[e-mail]>... Domain of sender address [e-mail] does not exist>

Iemand hier een idee over?

[Kabouterplop01]

Ik denk dat je maar 1 SMTP connector nodig hebt; de smarthost de "oude"UNIX baas.

[Verwijderd]

Kabouterplop01 schreef op 20 november 2003 @ 16:29:
Ik denk dat je maar 1 SMTP connector nodig hebt; de smarthost de "oude"UNIX baas.

Jip je hebt gelijk, dat werkt ook, op zich ook logisch. Maar wtf moet ik met die domain of sender adress does not exist??? Lijkt dus toch nog een DNS probleem, maar wat......

[Kabouterplop01]

Lijkt een beetje op een DNS probleem buiten jouw domein...
probeer deze link eens: https://www.zoneedit.com/lookup.html

Dan kun je een "NSlookup" doen naar waar de DNS staat verwezen. Vanaf buiten..
Dan weet je ook gelijk of jouw DNS goed staat

[Verwijderd]

Kabouterplop01 schreef op 21 november 2003 @ 10:31:
Lijkt een beetje op een DNS probleem buiten jouw domein...
probeer deze link eens: https://www.zoneedit.com/lookup.html

Dan kun je een "NSlookup" doen naar waar de DNS staat verwezen. Vanaf buiten..
Dan weet je ook gelijk of jouw DNS goed staat

HET WERKT!!!!!! toch een DNS probleem. Mbv masquerading opgelost..... Alleen dit was de testopstelling, nu naar de produktieomgeving. Bedankt voor alle hulp!!

[Kabouterplop01]

To configure the SMTP connector:
Start Exchange System Manager.
Expand the Administrative Groups container. To do so, click the plus sign (+) to the left of the container.
Click the administrative group that you want to work with, and then expand it.
Expand the Routing Groups container.
Click the routing group that you want to work with, and then expand it.
Click the Connectors container. Right-click the Connectors container, and then click New.
Click SMTP Connector.
On the General tab, provide an appropriate identifying name for the connector.
Choose to use DNS or forward to a smart host (if you are relaying through an Internet service provider send-mail server).
Under Local Bridgeheads, click Add. Add the server that becomes the bridgehead server for the routing group. Designate an SMTP virtual server as a bridgehead server for the SMTP connector.
Click the Address Space tab. Under Connector Scope, click either Entire Organization or Routing Group. As in earlier versions of Exchange Server, when you configure the Internet Mail Service, click Add, click SMTP, and then click OK. Accept the default (*) unless you require outbound e-mail domain restriction, and leave the cost as 1.
If you have chosen forward all mail to a smart host, click the Advanced tab. Click the Outbound Security option, and then select an appropriate authentication method for your relay host. The default is Anonymous Access.
Click OK to exit Outbound Security.
Click OK to exit the Advanced tab.
Click OK to exit the SMTP connector.
Quit the Microsoft Exchange Routing Engine service and the SMTP service for these changes to take effect.

[Verwijderd]

Kabouterplop01 schreef op 25 november 2003 @ 13:26:
To configure the SMTP connector:
Start Exchange System Manager.
Expand the Administrative Groups container. To do so, click the plus sign (+) to the left of the container.
Click the administrative group that you want to work with, and then expand it.
Expand the Routing Groups container.
Click the routing group that you want to work with, and then expand it.
Click the Connectors container. Right-click the Connectors container, and then click New.
Click SMTP Connector.
On the General tab, provide an appropriate identifying name for the connector.
Choose to use DNS or forward to a smart host (if you are relaying through an Internet service provider send-mail server).
Under Local Bridgeheads, click Add. Add the server that becomes the bridgehead server for the routing group. Designate an SMTP virtual server as a bridgehead server for the SMTP connector.
Click the Address Space tab. Under Connector Scope, click either Entire Organization or Routing Group. As in earlier versions of Exchange Server, when you configure the Internet Mail Service, click Add, click SMTP, and then click OK. Accept the default (*) unless you require outbound e-mail domain restriction, and leave the cost as 1.
If you have chosen forward all mail to a smart host, click the Advanced tab. Click the Outbound Security option, and then select an appropriate authentication method for your relay host. The default is Anonymous Access.
Click OK to exit Outbound Security.
Click OK to exit the Advanced tab.
Click OK to exit the SMTP connector.
Quit the Microsoft Exchange Routing Engine service and the SMTP service for these changes to take effect.

Ja dit had ik dus gedaan, het werkt fantastisch...... Thx anywayz!