etm030
asked on
Exchange 2000, OWA, logon problems
Several months ago I installed a new server onto our network and installed MS Exchange 2000 onto it. The server was a first server in a new AD Domain. In the old domain, there was a 5.5 Exchange server. Some users were converted using the Migration wizard, others were created fresh (but like named accounts existed on the old domain) and there are new users. Users can send and receive email just fine, and aside from some typical hoops and quirks, everything was going along fine.
Recently we decided to try and use OWA. The long and the short of it is that some users can connect and others cannot. Those that cannot are presented with the logon screen, enter ID and password (in any of the 3 proper formats), re peat three times and then get: HTTP/1.1 401 Unauthorized. The KBs that I have found at MS relate this problem to permissions and security and I have dutifully created a Group for everyone that is going to get OWA, and applied the recommended permission to the recomended folders and made approproiate Domain settings changes in the IIS MMC. Still nothing. The server on the old domain is still powered on, but MS Exchange services ore disabled (I tried enabling certain core ones and it changed nothing). I have scoured the registry of the new server and there are no references to the old Organization or OU. Logon fails in the same manner either insode or outside the firewall.
I though for a while that the users who could not log on were of a subset that had virtually identical accounts on the old and new systems, but were not imported through Migration Wizard. However, recently I have found one that falls into this group, but can access OWA. I have checked Advanced email Features and permissions are the same for both groups of users. I am totally lost on why there is a group that cannot logon when they seemingly have the exact same rights and permissions as those who can. Any ideas?
Recently we decided to try and use OWA. The long and the short of it is that some users can connect and others cannot. Those that cannot are presented with the logon screen, enter ID and password (in any of the 3 proper formats), re peat three times and then get: HTTP/1.1 401 Unauthorized. The KBs that I have found at MS relate this problem to permissions and security and I have dutifully created a Group for everyone that is going to get OWA, and applied the recommended permission to the recomended folders and made approproiate Domain settings changes in the IIS MMC. Still nothing. The server on the old domain is still powered on, but MS Exchange services ore disabled (I tried enabling certain core ones and it changed nothing). I have scoured the registry of the new server and there are no references to the old Organization or OU. Logon fails in the same manner either insode or outside the firewall.
I though for a while that the users who could not log on were of a subset that had virtually identical accounts on the old and new systems, but were not imported through Migration Wizard. However, recently I have found one that falls into this group, but can access OWA. I have checked Advanced email Features and permissions are the same for both groups of users. I am totally lost on why there is a group that cannot logon when they seemingly have the exact same rights and permissions as those who can. Any ideas?
ASKER
Yes, I have two domains. The server in the old domain remains on, but all Exchange services are disabled. I have tried leaving it off (it's on as a kind of security blanket, feel good thing for the owner of the company).
I created a Security Group that I called OWA. Into OWA I placed all the users who would need to access OWA, including users who cannot access it currently. I then gave OWA broad and liberal permissions starting at the wwwroot directory and also on to the exchweb folder. There are users, myself included, in the administrators group who cannot access OWA and others with no more permissions that the group Domain Users and OWA that can get in.
I created a Security Group that I called OWA. Into OWA I placed all the users who would need to access OWA, including users who cannot access it currently. I then gave OWA broad and liberal permissions starting at the wwwroot directory and also on to the exchweb folder. There are users, myself included, in the administrators group who cannot access OWA and others with no more permissions that the group Domain Users and OWA that can get in.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Just a quick solution idea:
6.) Have you ever tried to delete an account and recreate it. If this works, you could use a template user and just copy them, changing the names. But take care, if you delete users, you should notice, that you may have trouble with exchange mailboxes.
6.) Have you ever tried to delete an account and recreate it. If this works, you could use a template user and just copy them, changing the names. But take care, if you delete users, you should notice, that you may have trouble with exchange mailboxes.
ASKER
1.) Are the domains connected in any way (trust relationship).
No. But, they are on the same IP subnet.
2.) As this is user specific, try to find out, if this is machine specific (logon with an user which works onto a machine which do not work with the default user or vice versa)
It is not machine specific. I should have mentioned that earlier.
4.) Have you enabled the logging on you IIS for Web-Access? Ther you can see the requests and the responses.
No, but I'll do that tomorrow. I'll post the results, or at least a summary.
5.) Can you experience a common attribute for working / not working clients like Client OS, Browser Version etc.?
Unfortunately, not. If it doesn't work it doesn't work, period. Inside the firewall, or from the outside, from WIndows XP, 2000, or a 2003 T.S. session.
I have been a bit hesitant to go the delete route because I will need to delete both mailbox and user. To do so, I will have to export mailbox to a .pst file (average size about 500MB), delete the user, create a new user, and setup security again all over (There are about 20 Security Groups on the AD controller with all combination of members). Import the .pst and then test. Since I would need to do that about 20 times I'm not relishing the option.
No. But, they are on the same IP subnet.
2.) As this is user specific, try to find out, if this is machine specific (logon with an user which works onto a machine which do not work with the default user or vice versa)
It is not machine specific. I should have mentioned that earlier.
4.) Have you enabled the logging on you IIS for Web-Access? Ther you can see the requests and the responses.
No, but I'll do that tomorrow. I'll post the results, or at least a summary.
5.) Can you experience a common attribute for working / not working clients like Client OS, Browser Version etc.?
Unfortunately, not. If it doesn't work it doesn't work, period. Inside the firewall, or from the outside, from WIndows XP, 2000, or a 2003 T.S. session.
I have been a bit hesitant to go the delete route because I will need to delete both mailbox and user. To do so, I will have to export mailbox to a .pst file (average size about 500MB), delete the user, create a new user, and setup security again all over (There are about 20 Security Groups on the AD controller with all combination of members). Import the .pst and then test. Since I would need to do that about 20 times I'm not relishing the option.
I do not see when you mention changing the Domain Security Policy to allow log on locally.
Is there a pattern to the OWA issues with the users (aka, newly created mailboxes work and imported ones don't) ?
Have you chekced the allow http on the exchange tab of affected AD users?
Does "allow logon locally" in the default group policy editor solve the problem? Do you have multiple group policies?
-e
Have you chekced the allow http on the exchange tab of affected AD users?
Does "allow logon locally" in the default group policy editor solve the problem? Do you have multiple group policies?
-e
Allow logon locally:
Open AD users
Right click the default domain name tree and select properties
Select the group policy tab and click edit for the default policy
In Computer Configuration, Security, Local Policies, User Rights assignment, modify the log on locally object.
-e
Open AD users
Right click the default domain name tree and select properties
Select the group policy tab and click edit for the default policy
In Computer Configuration, Security, Local Policies, User Rights assignment, modify the log on locally object.
-e
ASKER
Logon locally is ruled out. All users can connect via our Terminal Server. As strange as this may sound, and I'm not 100% I'm leaning more to the position that the subset of users that cannot access OWA were created before the Exchange Migration wizard was run. There were a number of IDs created then to help with the transition of switching from the old domain to the new domain.
I created a new account tonight, created the mailbox, gave it nothing other than Groups Domain Users and OWA and it connects without any problems, yet the other accounts, some with the same Group assignments and others with privilege levels as high as Group Administrators still cannot connect.
I fear my only option is deleting the accounts, though I am going to try reloading SP3 and the rollup before I do that. Any other suggestions short of that I will gladly entertain.
I created a new account tonight, created the mailbox, gave it nothing other than Groups Domain Users and OWA and it connects without any problems, yet the other accounts, some with the same Group assignments and others with privilege levels as high as Group Administrators still cannot connect.
I fear my only option is deleting the accounts, though I am going to try reloading SP3 and the rollup before I do that. Any other suggestions short of that I will gladly entertain.
eedlee is correct first u have to establish which users can or cant.if it is
mix(some imported and some new users)who have this problem then it will
be very difficult to trouble shoot.but while u are troubleshooting rebuilt
and update ur recipient update services.also make sure all ur users have
the default recipient policy applied to them(are u using the same email
domain name or it has been changed?).
also if u have two domains both domains must be present in ur IIS.right click
on ur exchange directory and see what is the default domain next to
MODIFY.That domain must be present in all the users recipient policy
inorder for them to access ur OWA and if that is not possible then u must
create another virtual directory for the missing domain.
mix(some imported and some new users)who have this problem then it will
be very difficult to trouble shoot.but while u are troubleshooting rebuilt
and update ur recipient update services.also make sure all ur users have
the default recipient policy applied to them(are u using the same email
domain name or it has been changed?).
also if u have two domains both domains must be present in ur IIS.right click
on ur exchange directory and see what is the default domain next to
MODIFY.That domain must be present in all the users recipient policy
inorder for them to access ur OWA and if that is not possible then u must
create another virtual directory for the missing domain.
I am guessing you already went through all the tabs for an affected user, especially the Exchange tabs in AD users, and checked that each setting matches those for users who can connect. As Vahik states, it may be a receipient policy issue or email address domain name issue. These are typically resolved going through all the above options and matching the required parameters carefully.
Does anything appear in the event logs when a failing user tries to connect?
Does anything appear in the event logs when a failing user tries to connect?
ASKER
Does anything appear in the event logs when a failing user tries to connect?
If I enter the correct User ID and password nothing shows up, if I enter am incorrect password I get the typical message about inalid username or password.
Also, I rebuilt the recipient update service and tht did not help. I'm hoping to be able to reload the SP3 and rollup this weekend.
If I enter the correct User ID and password nothing shows up, if I enter am incorrect password I get the typical message about inalid username or password.
Also, I rebuilt the recipient update service and tht did not help. I'm hoping to be able to reload the SP3 and rollup this weekend.
Try resetting the password on one of the affected users and see if it solves the problem. it's possible that OWA defaulted on passwords during the migration process.
Lets follwow the idea to recreate the accounts. You will get a dialog, if the mailbox should be deleted or not, If you uncheck this issue, the mailbox will stay as unconnected mailbox within exchange, you can recreate the user and then reconnect the mailbox. Try this with your test user. If you have 20 mailboxes as you said, it would be an opinion.
Vahik, eedlee: Any know issues on that way?
Another idea: Do you have DHCP servers run? You now that only one DHCP server is allowed within a subnet? This may an issue, if your old server is a NT machine.
Vahik, eedlee: Any know issues on that way?
Another idea: Do you have DHCP servers run? You now that only one DHCP server is allowed within a subnet? This may an issue, if your old server is a NT machine.
bembi etm030 did not answer my question yet that if this problem was happening to the migrated users only or it was random.Or the problem users have the same recipient policy applied to them as the new users.But it does not matter since new users dont have this problem then deleting and recreating should be the solution.
RE:" bembi etm030 did not answer my question yet that if this problem was happening to the migrated users only or it was random "
Seems like a no-brainer at this point but I am betting that some GUID or SID corruption/mis-match occured during the import, and that ( although it is not determined ) that all the users who are havign the problem are in the imported category.
Seems like a no-brainer at this point but I am betting that some GUID or SID corruption/mis-match occured during the import, and that ( although it is not determined ) that all the users who are havign the problem are in the imported category.
ASKER
I spent some time this afternoon working on this some more and am 99% confident that the only users affected are the imported users.
"Another idea: Do you have DHCP servers run? You now that only one DHCP server is allowed within a subnet? This may an issue, if your old server is a NT machine."
Bembi, as a matter of fact, the only remaining function that the old NT machine serves is DHCP. IT's an item that has been on the check list, but not dealt with for no good reason other than something else always seems to come up when I think of switching it over.
"Lets follwow the idea to recreate the accounts. You will get a dialog, if the mailbox should be deleted or not, If you uncheck this issue, the mailbox will stay as unconnected mailbox within exchange, you can recreate the user and then reconnect the mailbox. Try this with your test user. If you have 20 mailboxes as you said, it would be an opinion."
I'll follow this if the DHCP thing does not fix this.
Thanks to everyone who has offered their help. If the DHCP server doesn't fix this, I'll dish out the points some time this week equally to all those who have offered their help/time. This is a great forum and I really appreciate the generousity you all extend here.
"Another idea: Do you have DHCP servers run? You now that only one DHCP server is allowed within a subnet? This may an issue, if your old server is a NT machine."
Bembi, as a matter of fact, the only remaining function that the old NT machine serves is DHCP. IT's an item that has been on the check list, but not dealt with for no good reason other than something else always seems to come up when I think of switching it over.
"Lets follwow the idea to recreate the accounts. You will get a dialog, if the mailbox should be deleted or not, If you uncheck this issue, the mailbox will stay as unconnected mailbox within exchange, you can recreate the user and then reconnect the mailbox. Try this with your test user. If you have 20 mailboxes as you said, it would be an opinion."
I'll follow this if the DHCP thing does not fix this.
Thanks to everyone who has offered their help. If the DHCP server doesn't fix this, I'll dish out the points some time this week equally to all those who have offered their help/time. This is a great forum and I really appreciate the generousity you all extend here.
In general: OWA is linked into the IIS. If you can connect by using outlook, but not by OWA, I would say, you have a permission problem within IIS. Where exactly have you changed permissions?