Hallo, I have a setup of 2 Exchange 2007 servers 2xCAS + MBOX plus an Exchange 2010 (not in use yet), 4 AD DCs and some more servers like BlackBerry. I am trying to switch off one of the DCs -- an old windows 2003 server. I have migrated the FMSO roles, updated the DNS setting on all servers and now I would like to switch off the 2003 AD DC. BUT: when I do this, everything works fine: * Mail goes in and out, * OWA works, * BlackBerry is fine, * Outlook 2003/2007/2010 with previously set-up accounts works just fine, * adding new accounts also seems to work. Except for I cannot configure a new account in Outlook (any version). When I create a new profile and configure an account I get: The bookmark is not valid afrer filling in the login and password. I am using the HTTP proxy for RPC (Outlook Anywhere is it called I guess). I verified the rpcredirect.dll manually using a web browser -- it seems OK -- empty page as the docs say. I checked the logs of the IIS -- no problem. I don't know where to search on the Exchange side :-( I googled and found some references to GC but I have a GC on every AD DC, so it should be fine. Also I found some references to OAB but I cannot see any problems with OAB -- well I don't know much about OAB :-( To quick-fix the problem I finally had to start the old AD DC again, but the problem persisted. Later after checking everything that came to my mind I rebooted the Exchage where the Outlook clients connect to and now I am up and running again (this proves that I have the Outlook client settings filled in right). I really need to remove the old windows server 2003 AD DC, so keeping it up is not a solution for me :-( Any tips and hints highly welcome. Regards, Martin Povolny

Yes, BookMark errors are GC problems. Now that you have rebooted the Exchange Server, if you down the DC you want to get rid of ( and I assume you have removed the GC role from this DC), do you still have problems? After removing the DC. confirm that Exchange is not using it by looking at the Event 2080 in the app log.

Thanks a lot for your input. I did not remove the GC role before. Now I tried to get into the situation you suggest. I did this: 1) removed the GC role from the old DC, checked the 2080 event on the Exchange, the "G" flag is gone, I can add new account to Outlook. so I had the role removed, old DC running and everything else OK 2) I turned off the old DC, now I cannot add new account to Outlook (still the same error) so again old DC down, cannot add account to Outlook 3) tried rebooting the Exchange -- no change cannot add acc to Outlook (still the same error) 4) I turned the old DC on again -- no change still cannot add acc to Outlook (still the same error) 5) tried rebooting the Exchange again -- no change, still the same now I have the same configuration as after step 1) but Outlook still not working as expected So now I guess I have to reenable the GC on the old DC and hope Exchange gets fixed again :-( UPDATE: 6) after reenabling GC on the old DC (event 2080 says Exchange sees the reenabled GC) -- still Outlook not working 7) after rebooting the Exchange, Outlook works again

Do the 2080 events show that the new DC is being used by Exchange as well? Can you post the 2080 events?

On Sun, 31 Oct 2010 16:44:14 +0000, Martin Povolny wrote: What version of Outlook are you using? That "bookmark" error can be a problem where Outlook is trying to use NSPI to read the GAL. If Outlook is using the Exchange referral service instead of trying to use the GC directly, that's one problem. But what happens if you put the name of the OLD GC into the server name when you create that new Outlook profile? Does that work? Does it work if you use the name of your new GC? That should avoid the Exchange referral service. Another problem may be happening if you've tried to restrict access to the GAL (http://support.microsoft.com/kb/948800). The Authenticated Users group should have the "GenericRead", "ListChildren" and "ReadProperty" AccessRights and the "Open-Address-Book" ExtendedRight on the GAL: Get-GlobalAddressList "Default Global Address List" | Get-ADPermission | where {$_.user -like "*Authenticated*"} | ft user,*right* User AccessRights ExtendedRights ---- ------------ -------------- NT AUTHORITY\Authenticated Users {GenericRead} NT AUTHORITY\Authenticated Users {ExtendedRight} {Open-Address-Book} NT AUTHORITY\Authenticated Users {ListChildren} NT AUTHORITY\Authenticated Users {ReadProperty} More below . . . >I did not remove the GC role before. > >Now I tried to get into the situation you suggest. I did this: > >1) removed the GC role from the old DC, checked the 2080 event on the Exchange, the "G" flag is gone, I can add new account to Outlook. >so I had the role removed, old DC running and everything else OK > >2) I turned off the old DC, now I cannot add new account to Outlook (still the same error) >so again old DC down, cannot add account to Outlook > >3) tried rebooting the Exchange -- no change cannot add acc to Outlook (still the same error) > >4) I turned the old DC on again -- no change still cannot add acc to Outlook (still the same error) > >5) tried rebooting the Exchange again -- no change, still the same > >now I have the same configuration as after step 1) but Outlook still not working as expected > >So now I guess I have to reenable the GC on the old DC and hope Exchange gets fixed again :-( > >UPDATE: >6) after reenabling GC on the old DC (event 2080 says Exchange sees the reenabled GC) -- still Outlook not working >7) after rebooting the Exchange, Outlook works again Have you tried rebooting both Global Catalog Servers? It sure sounds like one of them is having a problem with the NSPI. Have you verified that the SRV records for the GCs are correct? When you remove the GC from the old DC are the SRV records updated to reflect the change? What O/S is running the DCs? Are there any statically assigned DC or GC? Get-ExchangeServer <exchange-server> | fl *catalog*,*controller* --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Sure. I hope I am sending it in the format you assumed. This is now: Process STORE.EXE (PID=4952). 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: AD2.XXX CDG 1 7 7 1 0 1 1 7 1 ad3.XXX CDG 1 7 7 1 0 1 1 7 1 AD4.XXX CDG 1 7 7 1 0 1 1 7 1 ad5.XXX CDG 1 7 7 1 0 1 1 7 1 Out-of-site: this is when the AD2 was up but w/o the GC role: Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=220). 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: AD2.XXX CD- 1 6 6 0 0 1 1 6 1 ad3.XXX CDG 1 7 7 1 0 1 1 7 1 AD4.XXX CDG 1 7 7 1 0 1 1 7 1 ad5.XXX CDG 1 7 7 1 0 1 1 7 1 Out-of-site: this is when the AD2 was off Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=432). 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: ad3.XXX CDG 1 7 7 1 0 1 1 7 1 AD2.XXX CD- 1 0 0 0 0 0 0 0 0 AD4.XXX CDG 1 7 7 1 0 1 1 7 1 ad5.XXX CDG 1 7 7 1 0 1 1 7 1 Out-of-site: this is before that, when the AD2 was running (Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version) In-site: AD2.XXX CDG 1 7 7 1 0 1 1 7 1 ad3.XXX CDG 1 7 7 1 0 1 1 7 1 AD4.XXX CDG 1 7 7 1 0 1 1 7 1 ad5.XXX CDG 1 7 7 1 0 1 1 7 1 I don't know how to check which DC is being used (or what type use do you mean), but when I run the netstat on the Exchange server I see connections to ldap and msft-gc on several AD DCs like this: TCP mbx:1164 AD5:ldap ESTABLISHED TCP mbx:1169 AD2:ldap CLOSE_WAIT TCP mbx:1203 AD5:ldap ESTABLISHED TCP mbx:1209 AD5:ldap ESTABLISHED TCP mbx:1213 AD2:msft-gc CLOSE_WAIT TCP mbx:1219 AD5:ldap ESTABLISHED TCP mbx:1247 AD3:msft-gc ESTABLISHED TCP mbx:1249 AD2:msft-gc ESTABLISHED TCP mbx:1251 AD5:msft-gc ESTABLISHED TCP mbx:1253 AD4:msft-gc ESTABLISHED TCP mbx:1264 AD5:ldap ESTABLISHED TCP mbx:1278 AD5:ldap ESTABLISHED TCP mbx:1279 AD5:ldap ESTABLISHED So from that point of view all DCs seem to be used. Thanks for you time and regards! Martin Povolny

I was working with Outlook 2003, but a colleague of mine tried Outlook 2007 with simillar problems. I guess I cannot put in the name of the GC server when trying to configure the outlook because I am outside the network and I am connectiong through a RPC HTTPS proxy. That also puts NSPI out of the list of suspects, if I get right what NSPI is (please correct me if I am wrong). As to the permissions on the Global Address Lists -- I will take a look at it. Thank you for the tip. But that would cause problems no matter which GCs are on-line, would not it? (again please correct me if I am wrong, I am quite new to this stuff) I did not try rebooting any of the GCs except for the one that I am trying to remove. Should I try that? I have verified the GC SRV records -- all seem right -- both in the DNS admin utility and when I query them using nslookup. I have Exchange 2008R2 on 3 AD DCs and 2003 sp2 on the one that I am trying to remove. As to statically assigned DCs and GCs -- I hope not. I was trying to google how they can be staticly assigned in Exchange 2007 but did not find anything. The Organisation Configuration --> Modify Configuration Domain Controller is greyed-out, no value there. The option to assing a static GC that was in Exchange 2003 seems to be missing in Exchange 2007. [PS] C:\Documents and Settings\administrator>Get-ExchangeServer MBX | fl *catalog*, *controller* StaticGlobalCatalogs : {} CurrentGlobalCatalogs : {} StaticDomainControllers : {} StaticConfigDomainController : StaticExcludedDomainControllers : {} CurrentDomainControllers : {} CurrentConfigDomainController : All empty. Thanks for the tips, I will surely get back to the permissions you suggested as soon as possible. Regards Martin Povolny

On Sun, 31 Oct 2010 21:37:48 +0000, Martin Povolny wrote: >I was working with Outlook 2003, but a colleague of mine tried Outlook 2007 with simillar problems. I guess I cannot put in the name of the GC server when trying to configure the outlook because I am outside the network and I am connectiong through a RPC HTTPS proxy. That also puts NSPI out of the list of suspects, if I get right what NSPI is (please correct me if I am wrong). Well, not exactly. Those RPC requests are still being made but now they're in a HTTPS packet. The CAS server will use the RPC Proxy. But you're correct -- you cannot connect directly to the GC unless you've published that GUID using, say, ISA or TMG. Since you're using Outlook 2003, that leaves the AutoDiscover service out of the question too. Are you trying to create the Outlook profile while NOT using a VPN or LAN connection???? I've never had any great success at doing that. >As to the permissions on the Global Address Lists -- I will take a look at it. Thank you for the tip. But that would cause problems no matter which GCs are on-line, would not it? (again please correct me if I am wrong, I am quite new to this stuff) If the assumption is that everythng is working correctly that would be true. But check anyway. It only takes a moment. >I did not try rebooting any of the GCs except for the one that I am trying to remove. Should I try that? I would. It just eliminates one more thing from the list of "what could possibly be wrong". >I have verified the GC SRV records -- all seem right -- both in the DNS admin utility and when I query them using nslookup. I have Exchange 2008R2 on 3 AD DCs and 2003 sp2 on the one that I am trying to remove. As to statically assigned DCs and GCs -- I hope not. >I was trying to google how they can be staticly assigned in Exchange 2007 but did not find anything. You'd use the "set-exchangeserver" cmdlet to statically assign the GCs (and DCs). And, for the purpose of troubleshooting this, it might not be a bad idea to statically assign the DCs and GCs (leave the configuration DC alone, though) and NOT include the one DC/GC you're trying to remove. Keep reducing the list until you've either found the problem GC or until there's only one left -- and then swap that one for another of the ones you've already eliminated. You can try using the https://testexchangeconnectivity.com site to see if things are working properly. You can also download the Windows 2003 Server Resource Kit and use the rpcping tools (installed on the client) to verify the correct functioning of the RPC Proxy. http://support.microsoft.com/kb/831051 --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

You have decomissioned the old DC properly haven't you, i.e. removed the Active Directory services role using dcpromo. Just transferring FSMO roles and shutting down is not sufficent enough IMO as AD will still have pointers to the old server as a DC. When I decomission DC's I remove all roles brefore removing it from the domain (I tend to have AD, DNS and DHCP roles on my DC's).

> Since you're using Outlook 2003, that leaves the AutoDiscover service out of the question too. Are you trying to create the Outlook profile while NOT using a VPN or LAN connection???? I've never had any great success at doing that. Yes, I do. And w/o problems until I turn off the old AD DC. >>As to the permissions on the Global Address Lists -- I will take a look at it. Thank you for the tip. But that would cause problems no matter which GCs are on-line, would not it? (again please correct me if I am wrong, I am quite new to this stuff) > If the assumption is that everythng is working correctly that would be true. But check anyway. It only takes a moment. Well the permissions look fine. Probably not what you'd expect since I don't have one global address list, but several -- one for each mail domain, but it seems I have all the rights for the right groups. >> I did not try rebooting any of the GCs except for the one that I am trying to remove. Should I try that? > I would. It just eliminates one more thing from the list of "what could possibly be wrong". Ok, I will try rebooting them next time I try to turn down the old DC. > You'd use the "set-exchangeserver" cmdlet to statically assign the GCs (and DCs). And, for the purpose of troubleshooting this, it might not be a bad idea to statically assign the DCs and GCs (leave the configuration DC alone, though) and NOT include the one DC/GC you're trying to remove. Keep reducing the list until you've either found the problem GC or until there's only one left -- and then swap that one for another of the ones you've already eliminated. Thanks for the tip -- I will surely try this. > You can try using the https://testexchangeconnectivity.com site to see if things are working properly. Good tip. I used it to check the autodiscovery last week which seems to in quite a bad shape in my setup. I sort of inherited the setup and I am only slowly trying to fix things that seem to be strange or non-working :-( > You can also download the Windows 2003 Server Resource Kit and use the rpcping tools (installed on the client) to verify the correct functioning of the RPC Proxy. > http://support.microsoft.com/kb/831051 Again thanks for the tip -- I will take a look. I have also downloaded the OABInteg from the microsoft FTP, but it did not find any problems with the OAB either :-( I really wonder where the problem is. I have to say that I am disappointed by the poor quality of logging and lack of diagnostic tools in the MS world compared to my previous mostly UNIX experience :-( Debugging problems in MS infrastructure seems to be a real pain in the ... compared to *NIX-like OSes. Or maybe, I just lack the right skills....

I have not. I wanted to try to switch it off first. Then check that everything works and then remove it from the AD. I wanted to have the possibility to revert the step back in case anything goes wrong. But I hoped that in AD by switching one DC off I should have no problems given the FMSO roles are on another AD. But I may have read too much marketing materials ;-)

On Tue, 2 Nov 2010 14:55:08 +0000, Martin Povolny wrote: >> Since you're using Outlook 2003, that leaves the AutoDiscover service out of the question too. Are you trying to create the Outlook profile while NOT using a VPN or LAN connection???? I've never had any great success at doing that. >Yes, I do. And w/o problems until I turn off the old AD DC. I don't know it it will make a difference with RPC-over-HTTPS, but you could try adding the "UseClosestGC" registry value to the client: http://support.microsoft.com/kb/319206 Poke around in the registry (HLCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\<profilename>) and search for the name of the old GC. You should be able to change it to the name of the new GC. If you screw it up, just delete the profile and create a new one. The fact that the old GC is showing up in the profile at all leads me to believe that there's still "stuff" in DNS and AD that says it's till there. >>>As to the permissions on the Global Address Lists -- I will take a look at it. Thank you for the tip. But that would cause problems no matter which GCs are on-line, would not it? (again please correct me if I am wrong, I am quite new to this stuff) >> If the assumption is that everythng is working correctly that would be true. But check anyway. It only takes a moment. >Well the permissions look fine. Probably not what you'd expect since I don't have one global address list, but several -- one for each mail domain, but it seems I have all the rights for the right groups. http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/address-lists-exchange-2007-part1.html# >>> I did not try rebooting any of the GCs except for the one that I am trying to remove. Should I try that? >> I would. It just eliminates one more thing from the list of "what could possibly be wrong". >Ok, I will try rebooting them next time I try to turn down the old DC. >> You'd use the "set-exchangeserver" cmdlet to statically assign the GCs (and DCs). And, for the purpose of troubleshooting this, it might not be a bad idea to statically assign the DCs and GCs (leave the configuration DC alone, though) and NOT include the one DC/GC you're trying to remove. Keep reducing the list until you've either found the problem GC or until there's only one left -- and then swap that one for another of the ones you've already eliminated. >Thanks for the tip -- I will surely try this. >> You can try using the https://testexchangeconnectivity.com site to see if things are working properly. >Good tip. I used it to check the autodiscovery last week which seems to in quite a bad shape in my setup. I sort of inherited the setup and I am only slowly trying to fix things that seem to be strange or non-working >:-( >> You can also download the Windows 2003 Server Resource Kit and use the rpcping tools (installed on the client) to verify the correct functioning of the RPC Proxy. >> http://support.microsoft.com/kb/831051 >Again thanks for the tip -- I will take a look. I have also downloaded the OABInteg from the microsoft FTP, but it did not find any problems with the OAB either :-( I really wonder where the problem is. I have to say that I am disappointed by the poor quality of logging and lack of diagnostic tools in the MS world compared to my previous mostly UNIX experience :-( Debugging problems in MS infrastructure seems to be a real pain in the ... compared to *NIX-like OSes. Or maybe, I just lack the right skills.... --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP