OMA on Exchange 2003 stopped working after adprep for Win2K3 R2 and moving FSMO to new DC

We just ran ADPREP for adding 2 new WIndows 2003 R2 DCs on our domain. We moved FSMO roles and demoted the previous DCs in our domain. Exchange 2003 SP2 recognized the new DCs for Directory Access. All Exchange services were functional except OMA. RPC over HTTP Outlook client access, Webdav, and OWA are all still functional - although devices are failing to sync now. Any thoughts on what might have caused this to discontinue functioning?
rgeorge59Asked:
Who is Participating?
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.

SanDiegoComputerCommented:
Did you update the domain controller specified in the Recipient update services with a new Global Catalog server?  You say you verified that you checked the directory access.  I'm assuming you mean on the Directory access tab of the server properties.  
0

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
rgeorge59Author Commented:
The Recipient Update Services are pointing to the new GC server. We still are not able to get devices to sync. The Directory Access tab automatically generated the DCs via AD.
0
BusbarSolutions ArchitectCommented:
what is the error message  and is there is any thing in the event viewer
0
rgeorge59Author Commented:
I have resolved the issue. I believe that SanDiegoComputer resolved this issue for us and the issue was compounded from initial troubleshooting last night. Essentially here is what I did to resolve the issue:

I change RUS to point to a different DC this morning \\DC1r2. It was pointing to \\DC2r2 (which before the change was pointing to  \\DC2 that had the same name but this was an old LDAP reference to a server that was replaced yesterday via a dcpromo to demote \\DC2 and then a server rename and dcpromo to promote \\DC2r2). Since the Netbios names were identical RUS appeared to be correct. I did see a couple of events that showed this to be the issue right after you posted this recommendation so I changed RUS to point to \\DC1r2 and that error was resolved.

Secondly - yesterday's troubleshooting included reviewing Permissions in IIS for the Website for Exchange. I think somehow the selection was made to repush down the "require SSL" for the OMA virtual directories. I had event ID 3031 coming up and ensured Forms based Autg was disabled on our back end box, and enabled on the front end. I then made sure require SSL was disabled for the ActiveSync and OMA virtual directories and reset IIS. Voilas! Successs.

I gave credit to SanDiegoComputer as I feel that changing the RUS was the correct fix and the IIS perms were caused somehow yesterday during initial troubleshooting.

THank you all for your responses!
RG
0
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
Smartphones

From novice to tech pro — start learning today.

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.