• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2893
  • Last Modified:

The name could not be resolved. Network problems are preventing connection to the Microsoft Exchange Server computer. Contact your system administrator if this condition persists.

The Exchange server in our environment serves two domains, DOMAIN01 and DOMAIN02. Users in DOMAIN01 are unable to connect to Exchange via Outlook. They receive the error message "The name could not be resolved. Network problems are preventing connection to the Microsoft Exchange Server computer. Contact your system administrator if this condition persists" followed by the error message "The name could not be resolved. The action could not be completed".

This issue was only affecting a limited number of accounts until a few days, it seems, but now all users in DOMAIN01 appear to be affected. It appears that the trigger for this behaviour is password reset / expiry on the accounts.

No accounts in DOMAIN02 appear to be affected.

Users in DOMAIN01 are able to access their e-mail via Outlook Web Access (OWA) successfully. The problem appears to be with the Outlook 2000 client.

We have observed that if, within Exchange, we selected "Exchange General\Delivery Options\Add\Send on behalf of" and add the users' own account, it appears to remedy the situation.

We have hundreds of users, so this is not a practicable solution ultimately, but I hope that it will give some hint as to the root of the problem.

It feels as though it is authentication / permission related.

I am tempted to discount firewall issues because there have been no changes at a network level. Additionally, firewall rules would affect all computers in DOMAIN01 equally and simultaneously. We would not have seen the gradual password-expiry related issue.

0
inqude
Asked:
inqude
  • 3
  • 2
1 Solution
 
markpalinuxCommented:

What domain is the Exchange server?

Is there a trust between the two domains?

Is there a WINS/DNS issue between the two users in DOMAIN01 and the Exchange server?

From a workstation where a DOMAIN01 user is seeing the issue, can they click, start, run \\ExchangeServerName and see the default set of shared folders? I think "Address" is one can they click and open it up?

Thanks,
Mark
0
 
inqudeAuthor Commented:
Hi Mark,

There is a two way trust between DOMAIN01 and DOMAIN02, and WINS/DNS is working correctly. I can view the \\ExchangeServerName\Address share, for example, and I can resolve happily against the Exchange server with nslookup et cetera.

0
 
markpalinuxCommented:

Ok, lets think of what the pieces are and then try to figure out which piece is broken.

Basically there a a few things that could be the problem as I see it.

1 - networking - wins/dns appear to be working ( you can rpc to the exchange box from a workstation in DOMAIN01)
2 - domain trusts -
3 - permissions for exchange / the mailbox

And since a change to 3 ( the permissions you mentioned above  resolves an issue, )
May I suggest create a new mailbox  for a tets DOMAIN01 user to see if it also has the issue?
http://www.petri.co.il/self_permission_on_exchange_mailboxes.htm

I would start there, with a new test mailbox to see if it also has the issue. Maybe put it in a new test ou.

Were there are AD rights of Exchange rights Delegation Wizard, etc. changed?

www.joeware.net/freetools/ 
has some cool tools, adfind and admod that would let you script this type of permission change, problem would be is trying to find the correct parameters to use. Read the disclaimers, etc.

Mark
0
 
inqudeAuthor Commented:
Okay, I have several important pieces of information to add:

Firstly, after further investigation it became apparent that the global issue reported by our service desk was a completely unrelated issue affecting e-mail delivery. As far as I know, this specific problem is limited to one or two machines.

The situation I have reached is as follows:

I have two user accounts, DOMAIN01\USER01 (the user with the problem e-mail account DOMAIN02\PROBMAIL01) and DOMAIN01\USER02 (a copy of USER01), and I have assigned DOMAIN01\USER02 Full Mailbox access (from Mailbox Rights) to the problem e-mail account DOMAIN02\PROBMAIL01.

DOMAIN01\USER01 normally uses DOMAIN01\COMPUTER01
DOMAIN01\USER02 normally uses DOMAIN01\COMPUTER02

Basically, if DOMAIN01\USER01 tries to access DOMAIN02\PROBMAIL01 from DOMAIN01\COMPUTER01, it fails (which is the original problem).

If  DOMAIN01\USER01 tries to access DOMAIN02\PROBMAIL01 from DOMAIN01\COMPUTER02, it works.

If DOMAIN01\USER02 tries to access DOMAIN02\PROBMAIL01 from DOMAIN01\COMPUTER01, it fails in an identical way to the original problem.

If DOMAIN01\USER01 tries to access DOMAIN02\PROBMAIL01 from DOMAIN01\COMPUTER02, it works.

Thus, DOMAIN01\COMPUTER01 appears to be the problem.

I still have no idea why I am having problems accessing this account from this computer. However, I did notice the following:

When I am prompted to enter Microsoft Exchange server: and Mailbox: when I try to add the account, it makes no difference to the error message whether I enter valid or invalid server or mailbox names. Hence, if I say Microsoft Exchange server: WIBBLE and Mailbox: WOBBLE, it still errors in the same way.

This would seem to point back to a more fundamental WINS/DNS/network issue, but the original statement remains true: I can happily resolve the name of the Exchange server.
0
 
inqudeAuthor Commented:
Interestingly, we have had issues with computer AD account for this computer in the past, having difficulty in resetting it when the computer AD account has become corrupted.

This could be a contributing factor, but I do not understand enough about how this process works.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now