User cannot authenticate

I am at a loss of where to look, here is the brief overview:

3 DC's total, 2 are local in our office, 1 is at our data center.  1 Exchange 2007 server which was located at our office and was recently moved to the data center and put on the same subnet as the DC and is set to use this DC to authenticate user accounts.  All DC's are GC's.  Users at office are set to authenticate against local DC's via having them listed as their DNS servers via DHCP.  

Several BlackBerry users stared having issues when we moved our email server last Sunday to the data center where the could not connect.  Most of these users were fixed by deleting the old account via the account settings page on ATT&T's web site and then re-creating the account.  1 user was not so lucky and keeps getting a "cannot connect to the server" error.  I spent hours on the phone with blackberry the other day and could get some other accounts to authenticate to his phone but not his.  -What is weird is that I can setup his account on my iphone.... What is futher wierd is that I created a fake user while testing and could not get this user to setup on his blackberry and was recieving the same error.  Due to these last few observations I believed that this was a blackberry issue for sure, however as of today I am not too sure..... Today, several people said that they could not login to the their mail, most of which trying to use the OWA url.  Other people were locked out, and were not users that generally got locked out.  In all of these situations I was able to reset the persons pw and everything was working again, accept for my BB user.  Also, when looking at all of the authentication failures on the DC at the data center, I am now seeing several auth errors for the person that was having the blackberry issue, however these errors are being generated from his laptop via a VPN connection (he is a remote user).  I have gone through and reset the pw on all 3 DC's to make sure they all have the same pw and forced a replication to the other DC's however I am still seeing these issues.  I still cannot get his phone setup, though I can access our companies Outlook Web Interface and login with these new credentials just fine.  The only thing that I can think is that for some reason our Exchange server is somehow not passing the correct login credentials when trying to authenticate to a DC. -Any thoughts?

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Is it possible to do a wipe of the user BB?  Sounds like something is getting incorrectly cached on there.

Also, just a few other things I noticed, not necessarily related to your question

You may want to have 2 sites setup in AD Sites and Services.  One for your office, and the other for the datacenter.  Make sure your Exchange is in the correct site with the datacenter DC.

Also, even though your workstations have DNS pointing to your local DC's, does not 100% mean they will authenticate there.  They will look at a DC in the same site as them.  So if your Datacenter is in the same AD site as your local office, they may try to authenticate there.

As for the laptop that is out on the Internet trying to logon unsuccesfully - can you create a firewall rule to temporarily block it while testing?
tgrizzelAuthor Commented:
i may have not explained this very well as there are several things going on...:

The username is not BB  (BB = BlackBerry) and the account is 100% fine beyond the fact that we cannot re-setup his mail on his BB.  I thought this was an issue on the BB side, however I am now seeing other similar issues related to authentication problems.... One of which being the same user while he is VPN'd in; He is able to successfully VPN in (VPN uses our AD for auth) get to OWA, get to file shares, however I am seeing an audit failure comming from his VPN IP address.  Further, I created a test account called "thawk" and linked an email account to this.  I can VPN, access file share, access OWA with this account, however cannot setup a BB phone to get email (-though I can get an iphone or a windows mobile phone to work)  therefore wiping the persons AD account is not going to help as a new user account seems to have the same prob.

I do have another site setup for the data center and have specified the subnets that should be included in that site.  This does include the IP of both the DC and the Exchange server, as they are only 1 IP off from each other.

One thing that does bother me however is that when I go to EMC > Organization Configuration > Hub Transport > Send Connector > and then double click on one of my send connectors and look at Source Server, it shows that my email server is still listed in the site that encompasses my office, not the one that is at the data center.   If I try and delete this server and then Add it again it finds the server, but still has it listed in the old site.... my understanding is that there is no way to specify that this exchange server is in a new site except to list the correct subnet in the correct site..... is that correct?
I was referring to wiping the user's Blackberry (BB).  Not the user's account.  Sorry for not being more clear.  I missed the " 's " at the end of user......

Not sure what is going on with the Exchange server not showing up in the correct site.  But since everyone else is working ok, I don't think it's related to this issue.

tgrizzelAuthor Commented:
OK, I am narrowing down on the issue:

BB is not really the problem here.  When trying to setup BB to use OWA settings it would appear that on this account it is actually changing over to SMTP, and that may be where we have an issue.  When setting this up on an Iphone, it actually uses the OWA settings, however when setting this account up using IMAP, it fails here as well.  There may be a few problems: one of which I am now sure of is the fact that at least on the iphone, it tries to use port 587 for SMTP rather than 25.... we did not open this port in our firewall to get to the new subnet and will now need to do so.  

The second problem is that I still cannot pull mail using IMAP settings on either device (BB or Iphone using IMAP) therefore I would assume that the issue is on my side, and lies in authentication either over port 993, or some replication issue with my DC's.  I noticed something very odd when doing some testing though that is deffinetly an issue:  the Exchange server and the DC at the data center are in the same subnet, which is listed in the correct site in AD.  The other 2 DC's are in the subnet that is in our other "default first name" site.  Therefore, according to the theory that the exchange server should use the DC/GC in its site should make sure that the exchange server uses the DC at the data center to authenticate email login requests.  This is the case, as I can look in the security logs in that DC and see auth requests from the mail server.  On the other 2 DC's I do not see any user accounts/computers with failure or success entries in the security logs which further shows that the above theory is correct.  Here is where something is wrong though:  if I open dsa.msc on the exchange server, I should be opening the AD plugin on the server that is in the same site.... correct?  If I right click on the domain and go to the "Operations master" from this dsa.msc window, I see that it would appear that I am in the AD plug-in for the DC at the data center which would also be correct..... However, if I create a mail account within the EMC (Exchange Manager) and then immeadeatly start looking to see what DC this was created on, it does not show up on the DC that is in the same site...... It DOES show up immeadeatly in the 2 DC's at the office, in a different Site.  By observing this, it would appear to me that exchange server is still somehow logically connected to the original site rather than the new site that it should be in, however when trying to authenticate users it is going to the DC within its site.  

To test this further, once I had created this account on the exchange server I also tried to set this account up on my Iphone via normal OWA settings... This failed as the account was not yet created on the DC that the exchange server was trying to authenticate to.  However, I then forced replication to the 3 servers and found that as soon as the account was listed on the DC at the data center, the account was able to be setup via the OWA settings.  I then tried to reset the user password for the user that is still having issues with his BB phone on the server at our office, then force replication to the other servers, however I still could not get this to setup.

Does this bring anything out into the open that might be an issue then?
tgrizzelAuthor Commented:
I think part of this has been solved:

I found an article that said that an exchange server should have its own subnet listed in AD Sites and Services, therefore seperated these subnets out and now when creating an email address/user in Exchange via EMC, this shows on the DC located in its site first, and then replicates to the others.

Still having the other issues though.....

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.