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

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?
0
rgeorge59
Asked:
rgeorge59
  • 2
1 Solution
 
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
 
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

Featured Post

Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

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