OWA Works for some not all?

[suitz]

I am running Exchange 2000 - I have many users who login to their exchanges box via OWA. Some users are unable to access for no apparent reason while others have no problems at all.

I have created some of these user profiles as COPIES of a known profile that works through OWA and still it will not allow them to access?

When trying to login, the user is prompted for their LOGIN/PASSWORD/DOMAIN. After entering this information it immediately prompts them again and again for the same information and never allows them to login, nor does it provide any type of error message?

Is there a log somewhere I can check to see invalid login attempts?

 

[Davetoo]

You should post in the Exchange forum after searching for a solution, this is the Server forum.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

 

[ITPangaeaArchitect]

We're talking OWA here, so profiles have NO impact whatsoever on accessing the mailbox in this situation.
I would have to say initially, it sounds like a mailbox rights issue. It could potentially be something in the attributes of an affected user.
Is it possible to post an ldifde dump of both a working and non-working user in verbose mode from AD and post the output?

-Brandon Wilson
MCSE00/03, MCSA:Messaging00, MCSA03, A+

 

[terry712]

is the server running 2003
i have seen this behaviour if the ip chimneys are enabled
ie offlining the ip

you would see this in the evt log as it says something about exceeding 32 somethings

you would also see lots of mapi connections to the mailbox in question via exchange manager

 

[ITPangaeaArchitect]

well the chimney was just brought out ion win2003 sp2, so if you have SP2, it is a likely candidate. SP1 and before, not gonna be the chimney...

out of curiosity, are you using group policy to roll out IE settings...I have seen this occur many times due to internet options (advanced and zone level specifically). It may be worth checking a working users IE settings for all zones and for the advanced tab, then mimicking them via gpo to a single system currently not working, then check if it works. At a higher level, and an easier check, ensure a working and non-working systems have the same trusted sites, local intranet sites, restricted sites, etc.
Any differences can be fixed via gpo though...

-Brandon Wilson
MCSE00/03, MCSA:Messaging00, MCSA03, A+