Outlook/Exchange problem

[Smudger]

Please can someone help?

Primary DC server blew up, roles were seized on another DC and Global catalogue added to yet another DC but now Outlook clients cannot connect to exchange server even though we can ping it, remote console onto it and such. When a user tries to resolve the server name, either by IP or NetBIOS name, it comes up saying 'The name could not be resolved. The server containing the Global Address List is no longer available. You can reconnect to a different server by restarting Outlook or retry the operation when the server is available' Needless to say, restarting outlook doesn't work.
The name will resolve by inputting the new Primary DC's IP address instead of the exchange server, and this then resolves to the exchange server's name, however the client still cannot get into Outlook.

Exchange server is 2000 and clients are a mix of Office XP & 2000.

Any help would be gratefully received, I've been working at this all day, to no avail...

[Splash]

Exchange is on a seperate server to the deceased DC and the new GC, or the new GC?

[Smudger]

Exchange is on a server on its own, and the two DCs have nothing else on them other than DC stuff.

[Moby-Dick]

how is dns looking on the domain ?

[MaddAussie]

have you tried a 'ipconfig /flushdns' on the clients?

[Splash]

I assume you have forced a rebuild of the GAL? If you have and it's made no difference then I'd guess that as Moby says you're looking at DNS. Exchange box IP hasn't changed has it (this would be Very Bad, obviously)?

[Smudger]

The DNS is looking OK, I think, and some PCs worked until we flushed the DNS...

[Smudger]

I've forced a rebuild of the GAL, but it seems to be taking ages so I'm not sure if it's finished or not. We did have a brief period this afternoon where it seemed to be working, but only for two of us. The fact that one or two PCs (mine is one of them) can connect and most of the others can't puzzles me. The IP for Exchange hasn't changed...

[Splash]

I'm intrigued by the fact that some PCs stopped working after the DNS flush - this suggests that DNS is anything but peachy. A GAL rebuild can take some time dependent on your organisation size, but assuming that you're now officially out of hours you should be ok *fingers crossed*

[Smudger]

I'm intrigued by the fact that some PCs stopped working after the DNS flush - this suggests that DNS is anything but peachy. A GAL rebuild can take some time dependent on your organisation size, but assuming that you're now officially out of hours you should be ok *fingers crossed*

I think this might be the case. A GAL rebuild on the other DC was done really quickly but acheived nothing, so i think I'll just ahve to be patient for the other one.

Thanks for your input so far...

[badass]

Use NSlookup on both the PC's that have problems and PC's that don't. Compare results.
Post them here.
Post IPconfig /all results from working and not working PC's here.
If you need to, obfuscate sensitive names but leave us with enough to work out what is what.
If IP addresses start either 192.168.x.x, 172.x.x.x or 10.x.x.x then don't bother hiding them - they are private IPA's and no one can do anyting with them.

Also, check using the Exchange System manager to make sure that the exchange server isn't hard coded to talk to the blown up PDC emulator for anything.

[i4000]

Here's a couple of suggestions. This is from memory, as I don't have an Exchange console in front of me so sorry if the names are a little wrong.

1. Make sure your exchange server is using one of your online DC's
Open ESM
Right click on the server in question, select properties
Select the directory access tab
What DC's is your Exchange server using? Are they online? Pay particular attention to the GC

2. Make sure you DCs SRV records are correctly registered in DNS
Open the DNS console
Open the _msdcs.<root domain> zone
Check that all your DCs have 389 (LDAP) SRV records
Check that all your GCs have 3268 (GC) SRV records
Key places for 389 SRV records (within the _msdcs.<root domain> zone)
.dc._sites.site name._tcp
.dc._tcp
.domains.domain GUID._tcp
Key places for your 3268 SRV records (within the _msdcs.<root domain> zone)
.gc._sites.site name._tcp
.gc._tcp

If any of these SRV records are missing then it indicates a DNS, in this case try the following to get everything back up and running:

1. Nominate a single DC running DNS as the core DNS server
2. Configure all your DCs to use the nominated DC as it's primary DNS server
3. On your DCs execute the following:
ipconfig /registerdns - this forces the DCs to re-register their A records
restart (i.e. stop & start) the netlogon service on each DC - this forces the DCs to re-register their SRV records
4. In the _msdcs.<root domain> zone you should now see all the SRV records mentioned above
5. Configure everything else to use the nominated DC as it's primary DNS server (i.e. servers and clients - update DHCP scope options if neccessary for a large client estate).
6. Finally as a step for good measure restart the System Attendant on your Exchange servers, this should cause DSAccess to rebind to a DC

When you are at this stage, try doing a OAB rebuild

Some other thoughts:
What are you doing about the ex-DC? If it's not coming back (ever) then make sure it has been removed from ADUC and Sites & services, it's also probably worth doing a Metadata Cleanup from within NTDSUtil (search technet) to make sure all traces are really gone.

[Smudger]

I'll give those bits a try tomorrow. We found a work around by replacing the broken GC in the client registry with one of the new DCs, but I've spent most of the day having to update each computer manually. Group policy send didn't work...

[mikerr]

It's in situations like this that its handy to have OWA (Outlook Web Access) to fall back on in the meantime.

In fact at one company, they ended up staying with OWA as the client

[Moby-Dick]

exchange 2k OWA isn't pretty though.

[i4000]

exchange 2k OWA isn't pretty though.

Yuck