none
Cannot check name after global catalog move RRS feed

  • Question

  • I have a single forest with a single domain, and within it a single 2003 DC, and one 2007 exchange server, all on the same lan in the same location. I just promoted a new 2003 DC, made it the global catalog, and removed the global catalog from the old server. I've rebooted both DC's and the exchange server, and suddenly outlook 2007 clients cannot check name using the autodiscover info. Existing activesync and outlook clients work just fine - it is just authenticating that first time using the check name function. I cannot check name when manually adding a profile either. In exchange 2007 I see it is looking to the new server for its GC and DC, replication is working correctly for both DC's. All dcdiag and dcdiag dns tests are successful when run against the new server. If I check to enable GC on the old server and reboot everything, check name works again. 

    Seems to me like either exchange has the old GC hardcoded somewhere, or the new GC isn't responding/listening for this kind of request. Nothing useful in the eventlogs even after an hour or so of waiting and restarting services. 

    This seems to apply somewhat, but existing users with existing profiles authenticate and work properly, and the current GC is listed as such in EMC. http://support.microsoft.com/?id=927612 

    I'm not sure how to troubleshoot this further. Can anyone point me in the right direction of further troubleshooting steps, or where I should be looking inside exchange for addresses that it is using to look up this info?
    Saturday, April 27, 2013 3:18 PM

Answers

  • On Mon, 29 Apr 2013 19:08:46 +0000, giddyup05 wrote:
     
    >
    >
    >Yes, all FSMO roles have been transferred. Everything seems to work as expected except I do have this single error on the new DC:
    >
    >This server is the owner of the following FSMO role, but does not consider it valid.
     
    Isn't there more to that line of error text? Doesn't it say that the
    partition for that FSMO role hasn't replicated to all DCs?
     
    >FSMO Role: CN=Schema,CN=Configuration,DC=domain,DC=com
     
    This is a question better asked in a server platform forum. It may be
    related to DNS or to AD replication problems.
     
     
    >AD topology service logged the following when I could not check name after I removed the check mark for GC on the old server:
     
    I really don't think this is an Exchange problem. If your AD isn't
    healthy (which it may not be) Exchange isn't going to work right.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    • Marked as answer by giddyup05 Saturday, May 4, 2013 1:22 PM
    Tuesday, April 30, 2013 3:58 AM

All replies

  • On Sat, 27 Apr 2013 15:18:55 +0000, giddyup05 wrote:
     
    >I have a single forest with a single domain, and within it a single 2003 DC, and one 2007 exchange server, all on the same lan in the same location. I just promoted a new 2003 DC, made it the global catalog, and removed the global catalog from the old server. I've rebooted both DC's and the exchange server, and suddenly outlook 2007 clients cannot check name using the autodiscover info. Existing activesync and outlook clients work just fine - it is just authenticating that first time using the check name function. I cannot check name when manually adding a profile either.
     
    Is that true even if you use the name of the GC instead of the
    Exchange server when you create the profile?
     
    >In exchange 2007 I see it is looking to the new server for its GC and DC, replication is working correctly for both DC's. All dcdiag and dcdiag dns tests are successful when run against the new server. If I check to enable GC on the old server and reboot everything, check name works again.
    >
    >Seems to me like either exchange has the old GC hardcoded somewhere, or the new GC isn't responding/listening for this kind of request. Nothing useful in the eventlogs even after an hour or so of waiting and restarting services.
    >
    >This seems to apply somewhat, but existing users with existing profiles authenticate and work properly, and the current GC is listed as such in EMC. http://support.microsoft.com/?id=927612
    >
    >I'm not sure how to troubleshoot this further. Can anyone point me in the right direction of further troubleshooting steps, or where I should be looking inside exchange for addresses that it is using to look up this info?
     
    Is it possible the Outlook clients have been configured to use a
    specific GC?
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Saturday, April 27, 2013 7:45 PM
  • I haven't tested that but I will after hours in the next few days. So instead of the exchange server name in the exchange server field when adding the profile to outlook, use the GC name instead? I didn't realize you could do that. 

    I don't think they are configured to use a specific GC but it's possible. I'm running outlook 2007 on the new DC to test, and it's a brand new installation of office so I don't think it's set there. I just confirmed the DS Server key doesn't exist on the exchange server itself.

    Is there any way to test the correct functioning of this check name/directory lookup on the new GC? Or do you think it's just a matter of a piece of exchange isn't looking at the new GC for this lookup, even though the new DC/GC is listed on the system settings tab inside EMC?

    Sunday, April 28, 2013 5:24 PM
  • On Sun, 28 Apr 2013 17:24:47 +0000, giddyup05 wrote:
     
    >
    >
    >I haven't tested that but I will after hours in the next few days. So instead of the exchange server name in the exchange server field when adding the profile to outlook, use the GC name instead? I didn't realize you could do that.
    >
    >
    >
    >I don't think they are configured to use a specific GC but it's possible. I'm running outlook 2007 on the new DC to test, and it's a brand new installation of office so I don't think it's set there. I just confirmed the DS Server key doesn't exist on the exchange server itself.
    >
    >Is there any way to test the correct functioning of this check name/directory lookup on the new GC? Or do you think it's just a matter of a piece of exchange isn't looking at the new GC for this lookup, even though the new DC/GC is listed on the system settings tab inside EMC?
     
    Have you transferred the FSMO roles to the new DC?
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, April 28, 2013 9:28 PM
  • I am getting a KDC 20 log in the event log on the old DC. http://support.microsoft.com/kb/939088

    Since Outlook 2007 is trying to authenticate via Kerberos to the new DC/GC, could this have something to do with it?

    Monday, April 29, 2013 3:05 PM
  • Yes, all FSMO roles have been transferred. Everything seems to work as expected except I do have this single error on the new DC: 

    This server is the owner of the following FSMO role, but does not consider it valid. 

    FSMO Role: CN=Schema,CN=Configuration,DC=domain,DC=com 

    AD topology service logged the following when I could not check name after I removed the check mark for GC on the old server: 

    Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1264). Exchange Active Directory Provider has discovered the following servers with the following characteristics: 
    (Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version) 
    In-site: 
    oldserver.domain.com CD- 1 6 6 0 0 1 1 6 1 
    newserver.domain.com CDG 1 7 7 1 0 1 1 7 1 

    That looks good to me. 

    With both servers live and both as GC's, I started a new outlook profile and used the new server as the server name, and it correctly resolved to the exchange 2007 server name and everything worked - but I'm unsure if that's a solid test since the old server was still live/reachable and a GC.

    Do I need to restart the topology service or the whole server if I was to unplug the old server from the network for exchange to pick up and start using the new server as it's DC/GC? This is the current output of the topology service, since I had to add the GC role to the old server again:

    Process STORE.EXE (PID=1692). Exchange Active Directory Provider has discovered the following servers with the following characteristics: 
    (Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version) 
    In-site: 
    oldserver.domain.com CDG 1 7 7 1 0 1 1 7 1 
    newserver.domain.com CDG 1 7 7 1 0 1 1 7 1 

    Monday, April 29, 2013 7:08 PM
  • On Mon, 29 Apr 2013 19:08:46 +0000, giddyup05 wrote:
     
    >
    >
    >Yes, all FSMO roles have been transferred. Everything seems to work as expected except I do have this single error on the new DC:
    >
    >This server is the owner of the following FSMO role, but does not consider it valid.
     
    Isn't there more to that line of error text? Doesn't it say that the
    partition for that FSMO role hasn't replicated to all DCs?
     
    >FSMO Role: CN=Schema,CN=Configuration,DC=domain,DC=com
     
    This is a question better asked in a server platform forum. It may be
    related to DNS or to AD replication problems.
     
     
    >AD topology service logged the following when I could not check name after I removed the check mark for GC on the old server:
     
    I really don't think this is an Exchange problem. If your AD isn't
    healthy (which it may not be) Exchange isn't going to work right.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    • Marked as answer by giddyup05 Saturday, May 4, 2013 1:22 PM
    Tuesday, April 30, 2013 3:58 AM
  • Hi,

    Please try to specify GC for the problematic Outlook client:

    HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider

    For detailed steps, please refer to: http://support.microsoft.com/kb/319206

    Hope it is hlepful.


    Fiona Liao
    TechNet Community Support

    Tuesday, April 30, 2013 9:14 AM
    Moderator
  • Since dcdiag, repadmin /showrepl both come back clean, I'd expect this not to be an issue anymore. I wonder if I disconnected the network cable from the old server trying to test a little too soon, as some initial replication was going on, and now that they've both been up and online for a while have fully replicated and fixed themselves? The background replication schedule for a lot of Windows DC functionality is still a mystery to me.

    This is the full text of that error, and the last time it was logged was 4/26.


    This server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role. 
     
    Operations which require contacting a FSMO operation master will fail until this condition is corrected. 
     
    FSMO Role: CN=Schema,CN=Configuration,DC=domain,DC=com 
     
    User Action: 
     
    1. Initial synchronization is the first early replications done by a system as it is starting. A failure to initially synchronize may explain why a FSMO role cannot be validated. This process is explained in KB article 305476. 
    2. This server has one or more replication partners, and replication is failing for all of these partners. Use the command repadmin /showrepl to display the replication errors.  Correct the error in question. For example there maybe problems with IP connectivity, DNS name resolution, or security authentication that are preventing successful replication. 
    3. In the rare event that all replication partners being down is an expected occurance, perhaps because of maintenance or a disaster recovery, you can force the role to be validated. This can be done by using NTDSUTIL.EXE to seize the role to the same server. This may be done using the steps provided in KB articles 255504 and 324801 on http://support.microsoft.com. 
     
    The following operations may be impacted: 
    Schema: You will no longer be able to modify the schema for this forest. 
    Domain Naming: You will no longer be able to add or remove domains from this forest. 
    PDC: You will no longer be able to perform primary domain controller operations, such as Group Policy updates and password resets for non-Active Directory accounts. 
    RID: You will not be able to allocation new security identifiers for new user accounts, computer accounts or security groups. 
    Infrastructure: Cross-domain name references, such as universal group memberships, will not be updated properly if their target object is moved or renamed.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    If you think I should be posting in another forum I will. Thank you for all your help. 

    Tuesday, April 30, 2013 1:20 PM
  • On Tue, 30 Apr 2013 13:20:01 +0000, giddyup05 wrote:
     
    >Since dcdiag, repadmin /showrepl both come back clean, I'd expect this not to be an issue anymore. I wonder if I disconnected the network cable from the old server trying to test a little too soon, as some initial replication was going on, and now that they've both been up and online for a while have fully replicated and fixed themselves?
     
    Yes. If replication hadn't completed you'd certainly get errors like
    that.
     
    >The background replication schedule for a lot of Windows DC functionality is still a mystery to me.
     
    >This is the full text of that error, and the last time it was logged was 4/26.
    >
    >This server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role.
     
    That's what I was expecting to see. So replication problems (i.e. the
    inability to replicate) was at the bottom of it.
     
    [ snip ]
     
    >If you think I should be posting in another forum I will.
     
    If the AD isn't complaining any more there's no need to move your
    question. It's just that Exchange depends entirely on the AD and often
    gets the blame for things it has no control over.
     
    So, do you still have the orignal problem about being unable to
    resolve names when creating new Outlook profiles?
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, May 1, 2013 1:17 AM
  • The previous AD errors have seemed to clear up but I am getting a DNS error that the new DC can't resolve the old DC by it's msdcs cname, only when it's coming up after a reboot - but I am able to ping it and it resolves to the old dc's ip, so something is still going on.

    I haven't been on site outside of business hours to test if the check name issue is fixed. I'll try to do that soon and report back. 

    Wednesday, May 1, 2013 12:22 PM
  • On Wed, 1 May 2013 12:22:23 +0000, giddyup05 wrote:
     
    >The previous AD errors have seemed to clear up but I am getting a DNS error that the new DC can't resolve the old DC by it's msdcs cname, only when it's coming up after a reboot - but I am able to ping it and it resolves to the old dc's ip, so something is still going on.
     
    If the DNS service isn't up and running the DC won't be able to
    resolve addresses. Try making the primary DNS on the new server the IP
    address of the old server and vice-versa. Make the secondary DNS on
    the new server its own IP address and the same on the old server.
     
    >I haven't been on site outside of business hours to test if the check name issue is fixed. I'll try to do that soon and report back.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Thursday, May 2, 2013 1:26 AM
  • I posted in the Directory Services forum and got some advice. Looks like replication wasn't complete before I unplugged my old DC, and I assume that once I plugged it back in and waited, even DNS wasn't replicating correctly, so I had to point the both the old and new DC's primary DNS to the old DC, run ipconfig /registerdns and stop/start netlogon, I waited 15 minutes, saw no errors, rebooted the new DC and the AD errors I had were gone. Originally when I was having these problems both DC's were using the new DC as their primary DNS server, and I had done the previous commands, but for some reason all the records weren't there.

    I've since tested Exchange and the check name issue I had before is resolved. 

    Thanks for your help. I'll make sure AD is healthy next time before automatically blaming exchange. :)

    Saturday, May 4, 2013 1:21 PM