Forward exchange 2003 Relaying denied

Hi, I've tried to do the following steps
Forward exchange 2003 email to external account such as hotmail, yahoo, gmail
Simple step by step instructions to forward an exchange email to external email:
Step 1. Create new contact with external email address
1. On your exchange server, open active directory users and computers.
2. Right click users OU, point to new and click on contact.
3. Type the fill the user's information (first/last name) and click next.
4. Click modify and choose SMPT address.
4. Type the external email address and click ok and than click finish.
Step 2. Forward the internal email to the external email
Contact you created in step 1 will send the emails to the specify email address. All you need to now is to forward the exchange account emails to the contact. You can forward the emails or forward and leave a copy on the server for the local account.
1. On your exchange server, open active directory users and computers.
2. Select the AD user account, right click and click on properties or double click the account.
3. Click on Exchange General and than click on Delivery options.
4. Check off forward to, and click on Modify.
5. Find and select Contact account created on step 1.
6. Check off "Deliver message to both forwarding address and mailbox".
7. Click OK. Done.
But I've receive this mail while test it
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
Final-Recipient:
Action: failed
Status: 5.5.0
Diagnostic-Code: smtp;550 Recipient address rejected: Relaying denied
X-Display-Name: TecHeader

Hi Aviran,
I have had this problem before and found that the Outlook cache was the issue. might be worth trying this: http://support.microsoft.com/kb/287623
Hope that helps,
Shelly

Similar Messages

Unity Connection 8.5 single inbox with Exchange 2003 - Access denied

Hi,
I'm using CUCMBE 8.5.1.12900-7 Unrestricted. i'm following Unified Messaging Guide for Cisco Unity Connection Release 8.5 and Later for configuring single inbox. I have successfully setup and tested unified messaging service when I subscribe this service to a particular user and test it, I get following error:
Issue: Failed accessing [email protected] on 192.168.0.10
Recommendations: Some possible reasons for 401: Incorrect service account name or password. Service account password expired. Proper permissions not granted to service account. Exchange mailbox uninitialized.
Details: HTTP status=[401 Unauthorized] diagnostic=[Bad response from server, HTTP code returned: 401] url=[http://192.168.0.10/exchange/
[email protected]] request=[<?xml version="1.0"?> <D:propfind xmlns:D="DAV:" xmlns:fh="urn:schemas:httpmail:" xmlns:h="http://schemas.microsoft.com/repl/"> <D:prop> <fh:msgfolderroot/> </D:prop> </D:propfind> ] response=[<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>]
I have verified above mentioned recommendations but no such issue exists. Any ideas?

Hi Muhammad,
I am having exactly the same issue in configuring sinlgle inbox with unity connection 8.6 and exchange 2003. I have checked everything but no result. Could you please help in configuring?
Thanks
The validation results for the user unified messaging service account [email protected] with service E2K302 are the following:
Service "E2K302": AuthenticationMode=NTLM [use HTTP] Server=[E2K3-02.chelloit1.local] Type=[Exchange 2003] Username=[chelloit1.local\agokharu]
Failed accessing [email protected] on E2K3-02.chelloit1.local
Some possible reasons for 401: Incorrect service account name or password. Service account password expired. Proper permissions not granted to service account. Exchange mailbox uninitialized.
HTTP status=[401 Unauthorized] diagnostic=[Bad response from server, HTTP code returned: 401] url=[http://E2K3-02.chelloit1.local/exchange/[email protected]] request=[<?xml version="1.0"?> http://schemas.microsoft.com/repl/"> ] response=[ErrorError: Access is Denied.]

Exchange 2003 Permissions Error when attempting to forward emails

Server 2003 R2 (fully patched as of 11/2013) running Exchange 2003 SP2 (Built 7638.x2) on ESXi 4.1; WinXP clients and Server 2003 Terminal Servers running Outlook 2003; Domain and Forest are running at 2008 Functional Levels.
Occasionally, some users are receiving this error message: "You do not have sufficient permission to perform this operation on this object. See the folder contact or your system administrator" intermittently when attempting
to 1) forward email both to and from senders/recipients inside and outside the domain, 2) When attempting to modify the subject of a previously received email (I didn't know you could do that), 3) When attempting to open received attachments.
There is no discernible pattern to the users or the original senders of the emails.
Most of the results I've found when searching relate to NTFS permissions or a ReadOnly propery on items in the users's profile folder, or sending on behalf of another user - these either do not apply or have been verified as not the cause.
During the initial rash of problems when there was a problem with an attachment and we absolutely needed it, I was able to connect to OWA using a special administrative account with access to the mailbox, open the attachment and log out. Once I had
done so with this account, the end user was able to open the attachment on their own without a warning.
Changes made to the environment prior to this issue that may be related (nobody remembers when exactly this started, so I can't state that it definitively happened after this change):
All servers were virtualized on ESXi 4.1 in late 2011; subsequently converted and migrated to Hyper-V Server 2012 in early 2013 (with the exception of the Exchange and SQL servers).
All 2003/R2 domain controllers demoted and removed; DFL/FFL raised to 2008; SYSVOL replication was migrated from FRS to DFS-R.
Troubleshooting steps:
Exchange server and affected client computers have been restarted several times; the various exchange services have been restarted; permissions on the mailboxes and AD objects have been verified; event logs are generally clean with the exception of ActiveSync
errors for a single user not currently affected by forwarding emails, there are no other errors reported.
Per recommendations on another forum, I had enabled several diagnostic logs in the diagnostic logging tab of the server. Unfortunately not much was found in the Application log even after filtering out the basics. There were occasional errors
referencing User A failed to modify an item in User B's mailbox because access was denied; however, I was unable to correlate these errors to any reported incidence of the above message.
I created a new mailbox database on the same server and migrated all the mailboxes to the new database, there was no change; users immediately began seeing these errors.
Over a holiday weekend, I then spun up a new Win 2003 R2 server, with a fresh installation of Server 2003 R2 (also fully patched through 11/2013) running the same version of Exchange 2003 SP2 this time running as a virtual guest on Hyper-V Server 2012.
I migrated all mailboxes from the original mail server to the new mail server and it appeared that the problem was remedied; however, it has slowly started up again and is starting to become more frequent.
I'm really at my wits end with this problem and would like to get it resolved before we purchase and install our new Exchange Server later this year.

Updates
Users have reported that they can forward the email from OWA; even after doing so, they are unable to forward from Outlook. So either my previous notes on the issue were wrong, or this is just more of the "intermittent" nature of the problem.
I will have to investigate what logging options are available to me at the Outlook client level - any thoughts on that subject are also welcome.
Users have now reported that a previous (rarely used) workaround (the administrative account opening the email in OWA) no longer enables them to view attachments or forward emails in Outlook.
I'm still adjusting the various diagnostic logging settings to see if I can spot an event which corresponds to a reported occurrence. The most unusual warning reported is the following:
Source:MSExchangeIS Mailbox Store
Category: Access Control
Event ID: 1029
[email protected] failed an operation because the user did not have the following access rights:
'Delete' 'Read Property' 'Write Property' 'Create Message' 'View Item' 'Create Subfolder' 'Write Security Descriptor' 'Write Owner' 'Read Security Descriptor' 'Contact'
The distinguished name of the owning mailbox is /O=DOMAIN/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=USER_B. The folder ID is in the data section of this event.
However odd these occasional warnings are, they do not appears to correlate to the reported permissions issue. Everytime I've seen one of these events, I've inquired with "user_A" to see if they've recently seen the popup and in each case they have
not.

Message looping between Exchange 2003 & Exchange 2010 after domain type changed to internal relay

Hi
We have a coexistence environment where we are currently migrating from Exchange 2003 to 2010 and have 80% of the users already on the Exchange 2010 platform. This is all within the same AD forest, let's call it FOREST1.AD.
The problem I'm seeking help about is a message routing problem we had this morning where messages bound for the Exchange 2003 users started looping between Exchange 2003 and Exchange 2010. The problem started as a result of changing the accepted domain
type to 'internal relay domain' for the purposes of establishing SMTP namespace sharing with an external Exchange environment (different forest, let's call it FOREST2.AD). The expectation was that after changing the domain type from authoritative to 'internal
relay domain', Exchange 2010 would route messages for unknown recipients to the external environment and that would be the only effect of the change. The message routing to the external environment worked completely OK. However, later we noticed that Exchange
2003 stopped delivering messages to its local users and started routing them to Exchange 2010 which would route the messages back to Exchange 2003 as that's where the recipients existed, only to have Exchange 2003 send them back to Exchange 2010 again.
The Send connector to route the messages, for the shared namespace, to the external environment used the Exchange 2010 server as the source server. It makes sense and is expected that Exchange 2003 would send messages for any unknown recipients to Exchange
2010 for onward delivery via the Send connector. But it is not expected for Exchange 2003 to not deliver messages to its own users using the store driver and instead routing them on to Exchange 2010.
We fixed the problem by reversing the change and not only changed the domain type back to authoritative but also removed the Send connector for the specified shared namespace. However, we do need to understand why this problem happened and how to stop it
from happening.
We did test the shared SMTP namespace configuration using a test domain before applying the change to the domain that is used for production email traffic. Test users on Exchange 2003 with email addresses on the test domain did not experience this looping
problem. This has been tested again after the production domain experienced the problem and there is no looping for the test domain. The only difference I noticed between the configuration for the test domain and the production domain is that while both domains
existed as accepted domains of type 'internal relay domain' in Exchange 2010, there was a difference in configuration in Exchange 2003 where the test domain was not present on the recipient policy at all and the production domain was present there.
This also makes me wonder if Exchange 2003 and Exchange 2010 in the same organization keep a separate configuration to determine which domain they are authoritative for. When you install Exchange 2010, it does add all the domains on the recipient policies
to the accepted domains configuration but any new domains you add in accepted domains in Exchange 2010 are not added to the legacy recipient policy object.
Can someone please help clarify these grey areas and explain why the message looping was created and how to avoid it. I'm happy to provide any further information.
Thanks
Nauman.

Hello,
Why do you want to use the 'internal relay domain' authentication?
Thanks,
Simon Wu
TechNet Community Support

Exchange 2003 - bulk create smtp contacts from user objects, bulk forward to smtp contacts, bulk turn off forwarding

Exchange 2003 running on Windows server 2003. ~50 Users all in same OU on same domain with primary email address [email protected] objective is to create smtp contacts from each of the user objects imported back into the same domain in
a different OU with mail, targetAddress, proxyAddresses/SMTP on the contacts being [email protected] and the options 'automatically update email addresses based on recipient policy' disabled and hidden from GAL for all. At a later time will require
a method to bulk forward all of the user objects to their corresponding [email protected] contact object and a way to to bulk disable the forwarding at a later time.
ldifde created the contacts via export/import but Exchange seems to like rewriting the mail & proxyaddresses or replacing domain2.com with one of the internal recipient policy domains requiring manual change in AD.
ldifde -f export-01.ldf -s dc1.domain1.com -d "OU=Users,OU=people,DC=domain1,DC=com" -r "(&(objectCategory=person)(objectClass=user)(givenname=*))" -l "cn,givenName,objectclass,samAccountName,mail,physicalDeliveryOfficeName,displayName,name,description,sn,targetAddress"
ldifde -i -f import-test-01.ldf -s dc1.domain1.com
I'm then using ADModify.net to bulk modify hide from address lists attribute and correct the mail, targetaddress, proxyaddress attributes, possibly forwarding as well. The process is clunky compared to something like powershell on Exchange 2010.
Am I going about this the wrong way?

users will remain on the domain. decommissioning or altering access to the old mailboxes until some point post-migration would be unwanted so there's a fallback method in case anything goes wrong. until testing reveals a better method, the strategy
for Exchange 2003 / Server 2003 environment will remain as is for now using ldifde export of select user object attributes followed by ldifde import of select attributes to contact objects, followed by admodify.net / admodcmd updating of the necessary mail/exchange
attributes via %’mailNickName’% similar to what's described below to forward internal mail to the external host.
Using ADModify to Change Exchange Specific AD User Attributes in Bulk
Using ADModify – A real world example

Exchange 2003: Collab/Notification email relay issues

We use Exchange 2003 SMTP email server which is open internally and has relaying disabled.
The portal is installed on internal servers yet is having a problem sending notifications to external email addresses.
In the notification config file there are settings for email servers that have relaying disabled however this functionality doesn't work and the bug ticket for it has been opened for 4 years I'm told.
I'm wondering how smaller companies (<2000 employees) handle this issue.
Do you:
*enable relaying on your main email servers?
*setup a notification specific SMTP server?
*use a 3rd party email company?
What steps are there to reduce the threat of spammers and blacklists while still allowing email to be relayed?
I'm trying to work through this with our IT department but the idea of enabling relaying is a very touchy subject here as we have been burned by being blacklisted a few times in the past.
Thanks for any help!
Geoff

After going back and forth with Plumtree support for about 3 weeks we have solved the problem.
The problem came from a misunderstanding on what needed to be relayed. It turns out that external relaying is not needed, but internal relaying is.
Explicitly granting trust to the notification server allowed emails to begin flowing.
Geoff

Check forwarding email addresses on exchange 2003

We are moving to a hosted 2013 platform for emails
At the moment we a running of a 2003 exchange server
We are getting rid of almost 100 addresses that are no longer in use
They are currently forwarding to other address some even forwarding through 2 or 3 different accounts
Is there a tool or a quicker way to sort this mess out to see what aliases we
would need to set up?
Thanks for any advice given!
Cheers, Owen

You can not migrate from Exchange 2003 to Exchange 2013 directly so you need to go with two step approach like move to Exchange 2010 and then to Exchange 2013. - http://blogs.technet.com/b/mconeill/archive/2013/04/03/migration-from-exchange-2003-to-2013-a-no-go.aspx
You can get the list of users that are having some forwarding address set - https://exchangeshare.wordpress.com/2008/05/26/faq-find-all-users-with-forwarding-address-is-set/
Amit Tank | Exchange - MVP | Blog:
exchangeshare.wordpress.com

Relay issue from Unix across Exchange 2003 OWA server in Exchange 2010 environment

Hi,
I'm trying to resolve an issue. We have one Exchange 2003 server left in our environment. The rest is now Exchange 2010. We are working to decommission this server. Monitoring the SMTP logs, I am working with the various groups to get the traffic
off this server and onto the Exchange 2010 environment.
The issue we are finding is with a work flow. This Java app for eBis sends email to users. This is done correctly through Exchange 2010 and gets delivered from our HUB/CAS servers to the target user mailbox. This email has several links the user must click
for approving or rejecting requests. Upon clicking Approve, a new email window opens (we use Outlook 2010). The TO address is in the format of [email protected] Upon clicking Send, our Exchange 2010 HUB/CAS servers accept the
email, because one of our send connectors has, as address space, *.domain.corp. However, the email address being used it not an alias on any Exchange 2010 mailbox, so it appears Exchange 2010 is sending this email on to the Exchange 2003 server, which
also is an SMTP server. I *think* this server is looking at the address after @ to determine where to send it (ebisserver.domain.corp, which is valid in our DNS), and sends it on to that server, where the java "listener" program intercepts
the mail, processes it and then saves it to a file somewhere.
We are at a loss as to how to get Exchange 2010 to do this instead of Exchange 2003... once this traffic is eliminted from Exchange 2003, I can proceed with decommission of this server. Any help troubleshooting this issue is appreciated.

The only reason the Exchange 2010 server would route outbound mail through an Exchange 2003 server is that you have an SMTP Connector defined on the Exchange 2003 server that has a more specific domain than you have on the Exchange 2010 server. You
should be able to see all your Send Connectors (an SMTP Connector on Exchange 2003 looks like a Send Connector in Exchange 2010) by running Get-SendConnector.
Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Read/Unread, Replied, & Forwarded status not syncing with Exchange 2003 SP2

Is there a solution to the email status syncing issue for Microsoft Exchange 2003? It had never work since the day we setup the exchange account on the iphone. Any suggestion is appreciated.
I posted the above question in May 2009. iOS is now at 4.2.1, I guess Apple has no plan on addressing these. Would it work with the latest Microsoft Exchange?

Read/Unread worked for me when we were on Exchange 2003, and it continues to work now that we are on 2007. So it's probably an issue in your Exchange server.

Exchange 2003 SMTP resolves to incorrect MX record for Outbound emails

Starting October 2007, we have encountered numerous incidents where users complaint that they can not send emails to randomly with Relayed Denied error.
First we thought the problem is with the receipient servers, but after reviewing the SMTP log intensively, I have noticed that the SMTP service on Exchange Server 2003 SP2 tries to send out emails to wrong IP Addresses (instead of sending out to listed IP of MX record, it tries to send to primary domain IP address).
To test further, we have changed the DNS server of the Exchange Server to public DNS service provided by the ISPs and still received same result.
If the user tries to send the email again (from the bounced back message), it some times goes through.
Has anyone know what the problem is?
Have checked the server configuration, DNS configuration, ran all updates, and yet still same result. Is one of the Microsoft Updates causing this issue?

Here is the official explanation i got from MS, sounds like it is doing what they expect it to do.
Problem Description
When Exchange 2003 sends e-mail to the Internet using DNS to resolve external domain names a DNS query is done for the remote domain's MX records. In the event that the initial MX query returns a "server failure", Exchange 2003 will fall back to a DNS A record query. If this query is, in turn, successful and there is an A record for the domain in question that happens to be listening on port 25, Exchange will make a connection to that server. However, if this server does not relay, or accept e-mail for the intended domain a NDR will be generated with a 5.7.1, or
5.5.0 error message.
There are several domains that have A records that point to IP addresses that accept connections on port 25, but do not relay for the same name space:
Eg: Mindspring.com; Earthlink.net
Resolution
Resolve the DNS resolution problems that are causing occasional MX record failures.
Examples:
1. The Exchange server has multiple default gateways set on a multi-homed server.
This is not a recommended configuration and can cause a number of unexpected network problems. If the internal DNS server the internal NIC points to cannot resolve external DNS queries, this problem can occur.
Action: remove the default gateway from one of the NICs.
This doesn’t applies to us, as we don’t use Internal DNS
2. If the Exchange server points to multiple DNS servers on TCP/IP properties, or on the SMTP Virtual Server properties, verify that each of these DNS servers will return MX records properly. If one of the DNS servers does not return DNS records consistently, rectify this problem.
Action: remove this DNS server from the external DNS tab.
Workaround:
Bypass DNS by creating a SMTP connector with address space of <domain.com> and forward to smart host as the IP address the MX/A points to.
Exchange Query Explained
1. If Exchange finds the MX record(s) for a remote domain (through DNS query) it will not fall back to an A record query in the event the MX record (more precisely, the A record the MX record points to) is temporarily not responding on port 25. Instead, Exchange will try another MX record if one exists. If no other MX records exist and none are responding on port 25, the queue will go into a retry state for this remote domain. When that retry state has expired, Exchange will again attempt to resolve MX records for this domain, and so on.
2. Exchange will fall back to an A record query for the remote domain in the event that no MX record can be found. This is not to say that the MX record does not exist - only that when Exchange issued a DNS query for the remote domain the DNS response was "server failure", which basically means no MX was found. So, the MX record may indeed exist, but Exchange simply could not find it through DNS resolution.
3. Exchange then queries the A record and this happens to return a result. If the A record is listening on port 25, but does not accept mail for <domain.com> then we will get the NDR with 550 5.7.1 unable to relay (or some variation of this NDR error code) when Exchange connects and attempts to send the e-mail.
So, the intermittent nature of the problem is caused by a failure to find the MX record and a success in finding A record. This can happen for a variety of reasons, but it boils down to flakey DNS resolution.
For example:
a. A bad DNS server listed as a forwader on the DNS server.
b. A bad DNS server on the TCP/IP properties.
c. A bad DNS server on the SMTP VS (external DNS servers)
d. Multiple default gateways on Exchange (ie. multiple NICs on different networks, each NIC having a default GW)
A netmon on Exchange will show the failed MX lookup and successful A record lookup; however, it may not be conclusive unless the "bad" DNS server is listed in the netmon trace. For example, if Exchange points to internal DNS server(s) for name resolution and these DNS servers service these DNS queries by Exchange, you may need a netmon on the DNS server(s) as well to determine which DNS server/Forwarder/etc is at fault.
Regards,
Shahul Hameed Dasthagir
Support Engineer | Enterprise Communications Support

Exchange 2003 to 2010 migration mailflow issue

Hello,
I have a server 2003 w/ exchange 2003 that we are upgrading to 2010 to support Outlook 2013.
So we installed a windows 2008 server and exchange 2010. We followed a guide to help with the different steps and didn't have problem or error until now.
So what we have right now, is exchange 2003 with still ALL mailboxes.
Replications of folders is done.
Policies are updated.
The firewall is forwarding port 25 to the new exchange 2010 server:
Emails are coming in fine.
Internal emails are also perfectly fine (from internal user to internal users).
the only thing that is giving us trouble is the emails coming out. None of them are going out and they are getting "stuck" in the "routing group connector" on the 2003 machine.
The 2010 exchange has a simple send connector set SMTP/* with this server as source. The 2003 exchange only had the exch2003-exch2010 connector.
Because emails were kind of accumulating (80+) I decided to take the send connector on the 2010 exchange out. and added back a send connector on the 2003 exchange. This kind of "fixed" it as now all emails are going just fine. It also fixed
the queue as part of it got liberated when I added the 2003 send connector.
I still have 25 emails stuck in this "routing group connector" that I'd like to take care of.
We are obviously not done with the migration and this coexistence phase as actual mailboxes still need to be moved.
So I'd like to take care of this queue in the routing group connector as well as continue the process of being able to receive and send from the 2010 machine only. then I would continue the migration process.
FYI, the 2003-2010 connector was created using power shell on the 2010 machine. I am not using any smarthost.
and the error message (in the queue) I get is: "unable to bind to the destination server in DNS"
FYI, my 2003 server is called "SERVER1" and the 2010 server is "SERVER2", they're on the same local domain company.local.
FYI (not sure if that's relevant), the server1 exchange has a different certificate (different domain name) than the new server (server2) as our web host finally allowed us to use subdomains. not trying to confuse anyone but I am really stuck there and maybe
this is related: certificate for the exchange 2003 machine: www.company-mail.com (only 1) and certificates for the exchange 2010 are: mail.company.com / autodiscover.company.com (and a legacy.company.com we may not need since the actual coexistence phase will/should
be short).
any idea what's wrong here?

I added back the send connector on the 2010 exchange. everything still works fine since I still have the send connector on the 2003. However...
I connected through telnet to server2 (the exchange 2010) and was able to mail internally. however I couldn't send mail externally, it gives me a "cannot relay" error when I enter my rcpt to:... command.
I am guessing that this may be the reason why the queue is not emptying itself through that send connector.
Anything else I could try to test my "send connector" on the 2010 exchange?

Exchange 2003 decommission steps

Hello,
Are these the right steps to decommission exchange 2003?
Task Name
Create new SMTP connector
Create new send connector
Move Public folders
Exchange OAB
Remove mailbox Database
Routing group connectors
Recipient policy's
Kind Regards,
PenDraKon

1. Please make sure that all the clients have connected to the new Exchange server at least once. - What do you mean?
2. Ensure that mail flow in your Exchange server doesn't depend on services that are running on legacy Exchange server. How do I check this please?
1. I believe this is referencing to ensure all your end user clients are pointing to the Exchange 2007/2010 CAS. I would assume this has already happened if you already moved all your mailboxes to off of the Exchange 2003 servers. Unless you
have end users complaining they cannot access their email, they should be accessing migrated mailboxes through the newer CAS roles installed.
2. Ensure that you don't have any internal relays, such as for network devices or internal alerting systems, that require Exchange 2003 to receive SMTP. You may have to configure additional receive connectors scoped to specific purposes to allow
internal applications or devices to send email (non-Outlook clients). Also, Are there any other services, such as message hygiene applications that accept inbound messages first the forward into Exchange that reside on those Exchange 2003 servers?
As long as inbound email is being routed through Exchange 2007/2010 and outbound email is being sent through the HT roles directly using DNS routing or a specific smarthost that is not on your Exchange 2003 servers, you should be good.

Exchange 2003 to GroupWise 7

We are not able to successfully complete a migration of all users from
Exchange 2003 to GroupWise 7 on Netware. Issues below:
** NOT Necessarily in exact order of sequence **
System config:
Netware OES fully service packed, new server, 4GB RAM, 4 Processors.
GroupWise 7.0.1 IR1 Post Office installed. Domain located on an older,
existing server.
Microsoft Windows Server 2003, Exchange 2003 single server. Nothing
special or unusual about this setup for Exchange, pretty generic.
1. Issue attempting to install Migration utility. Utility unable to run
after installation on any workstation. Various errors from "unable to
create GroupWise account" to "unable to login to Exchange mailbox" and a
few others. We also got "fatal errors when trying to extract .csv file".
This was resolved later by running fixmapi.
2. After nearly 18 hours attempting to get the utility to work, we were
able to successfully load it onto 2 workstations. It appeared that it
would work on both.
3. We tried many things to install and run the utility on 15 additional
workstations with no success.
4. Found that the only 2 workstations that appeared to run the utility
were fairly new, less than 2 months old. We then tried fresh installations
of WINXP and WIN2000 on 2 workstations with no success. One of the 2
workstations that did work, later no longer would run the utility. After
running fixmapi.exe on that workstation, it did again work.
5. A suggestion from Novell NTS was to run fixmapi.exe. This appeared to
have corrected 4 of the 10 workstations on which we tried it.
6. Found on 2 workstations that if ZEN DLU (Dynamic Local User) was used,
the migration utility did not work. We found this by logging in as
"Workstation Only" which connected the workstation to the domain, then a
login to eDirectory. The utility did work. So, again we tried to login on
startup to eDirectory and again were not able to run the utility. So, the
fact that some workstations here use DLU may be an issue for this utility.
7. Found that on other workstations, the utility would run ONLY if
"Workstation Only" was selected, then login to eDirectory. We were able to
repeat this sequence multiple times. This is on a workstation not running
ZEN DLU.
8. Of the 6 workstations we were able to run the utility, 1 failed in the
first 5 minutes and would no longer work. So, we split the .csv file from
the Exchange server into 5 parts and started the migration on the 5
available operating workstations. Of the 5, only 2 completed the utility.
Of those 2, only 7 of the 45 users to be migrated completed on 1
workstation and 15 of 45 completed on another.
9. On the 2 workstations that completed, all user accounts were created
but the utility was unable to access the GroupWise account. Login to
GroupWise account failed.
10. Migration utility rules creation issue. There are 2 issues here.
10a. The utility suggests to create a rule using a sub-domain and a
forward rule in Exchange to the new GroupWise system. We are migrating
from: royalmouldings.com to ggc.com. So, the sub-domain is
marexch.ggc.com. The rule would read "forward all mail to
[email protected]. However, Exchange cannot forward to an external
domain at the client level. The only means to do so is to create a contact
in AD with an SMTP email address of the domain to be forwarded to. Then,
in the users account a rule may be created to forward to that newly
created contact. The fact that we are forwarding to an external internet
domain, as in NOT the same one currently used in Exchange, is not
indicated in the documentation. Additionally, if anyone is to do this, a
lot of manual work must be done to accomplish this task. Not too practical
to do for hundreds or thousands of users. This has been a big problem as a
result of the large amount of users in the system and the time it takes to
create each of these contacts.
10b. The second issue is the fact that the rule was created for 1 user,
then no other users had the rule created. So, even if the rule were to
work or we were migrating from and to the same domain name, we'd still
have the rule issue as it was never again created by the utility after the
first user was migrated.
Any help would be greatly appreciated.
Thanks

Bill, you're understandably frustrated. I have a couple of comments.
1. The network authentication system used by Microsoft Exchange requires that you log in to your workstation with the same user ID and password as your account on Exchange. If they don't match, Exchange returns errors that are not always understandable. That might explain why Zen DLU has problems.
2. It seems that every application that deals with e-mail has its own version of MAPI, and they're not always compatible with each other. Outlook, GroupWise, and the migration utility all use MAPI. The fixmapi utility will restore the MAPI DLLs that Outlook expects, which is usually the version that works best.
3. The migration utility should be improved to detect potential errors like these.
>>> Bill Long<[email protected]> 5/19/07 11:59 AM >>>
We are not able to successfully complete a migration of all users from
Exchange 2003 to GroupWise 7 on Netware. Issues below:
** NOT Necessarily in exact order of sequence **
System config:
Netware OES fully service packed, new server, 4GB RAM, 4 Processors.
GroupWise 7.0.1 IR1 Post Office installed. Domain located on an older,
existing server.
Microsoft Windows Server 2003, Exchange 2003 single server. Nothing
special or unusual about this setup for Exchange, pretty generic.
1. Issue attempting to install Migration utility. Utility unable to run
after installation on any workstation. Various errors from "unable to
create GroupWise account" to "unable to login to Exchange mailbox" and a
few others. We also got "fatal errors when trying to extract .csv file".
This was resolved later by running fixmapi.
2. After nearly 18 hours attempting to get the utility to work, we were
able to successfully load it onto 2 workstations. It appeared that it
would work on both.
3. We tried many things to install and run the utility on 15 additional
workstations with no success.
4. Found that the only 2 workstations that appeared to run the utility
were fairly new, less than 2 months old. We then tried fresh installations
of WINXP and WIN2000 on 2 workstations with no success. One of the 2
workstations that did work, later no longer would run the utility. After
running fixmapi.exe on that workstation, it did again work.
5. A suggestion from Novell NTS was to run fixmapi.exe. This appeared to
have corrected 4 of the 10 workstations on which we tried it.
6. Found on 2 workstations that if ZEN DLU (Dynamic Local User) was used,
the migration utility did not work. We found this by logging in as
"Workstation Only" which connected the workstation to the domain, then a
login to eDirectory. The utility did work. So, again we tried to login on
startup to eDirectory and again were not able to run the utility. So, the
fact that some workstations here use DLU may be an issue for this utility.
7. Found that on other workstations, the utility would run ONLY if
"Workstation Only" was selected, then login to eDirectory. We were able to
repeat this sequence multiple times. This is on a workstation not running
ZEN DLU.
8. Of the 6 workstations we were able to run the utility, 1 failed in the
first 5 minutes and would no longer work. So, we split the .csv file from
the Exchange server into 5 parts and started the migration on the 5
available operating workstations. Of the 5, only 2 completed the utility.
Of those 2, only 7 of the 45 users to be migrated completed on 1
workstation and 15 of 45 completed on another.
9. On the 2 workstations that completed, all user accounts were created
but the utility was unable to access the GroupWise account. Login to
GroupWise account failed.
10. Migration utility rules creation issue. There are 2 issues here.
10a. The utility suggests to create a rule using a sub-domain and a
forward rule in Exchange to the new GroupWise system. We are migrating
from: royalmouldings.com to ggc.com. So, the sub-domain is
marexch.ggc.com. The rule would read "forward all mail to
[email protected]. However, Exchange cannot forward to an external
domain at the client level. The only means to do so is to create a contact
in AD with an SMTP email address of the domain to be forwarded to. Then,
in the users account a rule may be created to forward to that newly
created contact. The fact that we are forwarding to an external internet
domain, as in NOT the same one currently used in Exchange, is not
indicated in the documentation. Additionally, if anyone is to do this, a
lot of manual work must be done to accomplish this task. Not too practical
to do for hundreds or thousands of users. This has been a big problem as a
result of the large amount of users in the system and the time it takes to
create each of these contacts.
10b. The second issue is the fact that the rule was created for 1 user,
then no other users had the rule created. So, even if the rule were to
work or we were migrating from and to the same domain name, we'd still
have the rule issue as it was never again created by the utility after the
first user was migrated.
Any help would be greatly appreciated.
Thanks

Removing dead Exchange 2003 and Exchange 2000 Server from the domain

Hi Team,
I have come across a client who wants to migrate to O365 from existing Exchange 2003 environment through the Hybrid Model. I am trying to introduce 2010 Sp3 to the environment. While checking the environment using Exchange pre-deployment found 2 servers
in the environment which is not present on the network now. Client has no clue what they are.
One is Exchange 2003 and the other is Exchange 2000. The problem here is i cannot introduce Exchange 2010 Sp3 unless all the Exchange servers are running minimum Exchange 2003 Sp2.
At present i find only 2 exchange 2003 Sp2 server which are in production. Need kind assistance to move forward.

Hi,
I recommend you follow the steps below:
1. Please upgrade Exchange 2000 and Exchange 2003 to Exchange 2003 SP2 at first.
2. Deploy Exchange 2010 servers in this order: CAS, Hub, UM and Mailbox. For more information, here is an article for your reference:
Exchange 2003 - Planning Roadmap for Upgrade and Coexistence
http://technet.microsoft.com/en-us/library/aa998186(v=exchg.141).aspx
3. Install Exchange 2010 SP3.
Here is an article for your reference.
Upgrade Exchange 2010 to Exchange 2010 SP1, Exchange 2010 SP2, or Exchange 2010 SP3
http://technet.microsoft.com/en-us/library/bb629560(v=exchg.141).aspx
About a hybrid deployment with Microsoft Office 365 using Microsoft Exchange Server 2010 servers, here is an article for your reference.
Understanding Upgrading Office 365 Tenants for Exchange 2010-based Hybrid Deployments
http://technet.microsoft.com/en-us/library/jj945383(v=exchg.141).aspx
Hope it helps.
If there are any problems, please feel free to let me know.
Best regards,
Amy
Amy Wang
TechNet Community Support

Exchange 2003 -2010 cross forest (NDR 5.4.6)

Hi.
Have: Exchange 2003+2010 in source forest. Exchange 2010 in target forest.
Successful migrate mailbox to target forest (in source forest this mailbox convert to mailuser).
When try send e-mail to this mailbox (it`s in target forest) from Exchange 2003 mailbox get this:
A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients.
If send from Exchange 2010 (source/target) - all mail ok.
If delete this mailuser (in source forest) - all set to ok.
x500?
Please, help.
Thanks.

Hi,
In the error event, 5.4.6 means "Routing loop detected" (RFC1893).
This issue occurs if the source Exchange organization is authoritative for the target domain. Because the source Exchange organization is responsible for mail delivery to target, the categorizer tries to find locally a recipient for
that message. The categorizer does not succeed, and then you receive the NDR.
More details in the following KB:
You receive an NDR with a 5.4.6 status code when you send a message to a specific domain in Exchange
http://support.microsoft.com/kb/324732/en-us
Hope it is the solution.
Thanks
Mavis
Mavis Huang
TechNet Community Support

Forward exchange 2003 Relaying denied

Similar Messages

Maybe you are looking for