Paul's esoteric meanderings

I find it fairly frequent that I have to assist a company redesign or improve their exchange infrastructure. When changing servers around Move Mailbox is a particularly handy tool. There is an absolute dearth of information on the Outlook side of things however. Here is a few things I have found that may be useful.

When you move a mailbox Outlook will (generally) get redirected without issue. It will do this by connecting to the original server, whop will then issue an instruction as to the new mailbox location based on what information is stored in AD. Some (5% or less) will not automatically redirect due to dodgy profiles.

If you have to do a server shuffle due to hardware limitations, that is, move everyone to another server, rebuild the first one, then move them back, you may have problems. As soon as you turn off the original server, any users not yet redirected will not be able to open outlook. Anyone that has already been redirected will be fine. For sites were staff are on rosters this can leave a large number or “orphaned” copies of outlook. Luckily the solution turns out to be simple.

Outlook merely looks at the server name to find the Exchange Server. It’s not based on the computer account or GUID. This means that if you delete the original server and rebuild a temporary one with the same name, it will handle all the redirections for you. It doesn’t matter the mailbox is no longer there, all the data is stored in AD. You could even throw it onto a VM, it doesn’t do any work, and needs very little disk space. 

This makes a migration where you want to keep everything smooth for your users even simpler.  I just finished using it as I had to to totally reconfigure the RAID packs on a server, meaning the mailboxes just had to move.

Active Directory uses the _msdcs.domain.local sub-domain to host SRV records. Depending on your domain structure and upgrade path, you may find this domain delegated rather than held as part of your “domain.local” zone. The conditions are in this KB article.

Now lets get tricky. Let’s say your _msdcs is delegated as in the picture above. Let’s also say over the years you replace and upgrade servers as your network grows. Sooner or later you’ll most likely replace your original domain controllers.

Well – the delegation details don’t get automatically updated with the IP of every server that hosts the zone. Nup, they are static. This means that although you may have 10 replicas scattered across your network, only the original DNS servers will be the ones listed as Authoritative. When they are replaced – presto – broken DNS and all sorts of cool errors. I recommend DCDiag /test:dns to look for things like this.

So if you are adding or removing DC’s, add _msdcs delegation to your checklist.

Now why wouldn’t MS simply have any replica automatically be listed?

One of the errors is below – Event ID 2087

Active Directory could not resolve the following DNS host name of the source domain controller to an IP address. This error prevents additions, deletions and changes in Active Directory from replicating between one or more domain controllers in the forest. Security groups, group policy, users and computers and their passwords will be inconsistent between domain controllers until this error is resolved, potentially affecting logon authentication and access to network resources.

Source domain controller:

 abcdc03

Failing DNS host name:

 568a7f0d-ef3a-4fad-b7bc-5d5d8ce17ba2._msdcs.abc.com.id

NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur.  To log all individual failure events, set the following diagnostics registry value to 1:

Registry Path:

HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client

User Action:

 1) If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller’s metadata with ntdsutil.exe, using the steps outlined in MSKB article 216498.

 2) Confirm that the source domain controller is running Active directory and is accessible on the network by typing “net view \\<source DC name>” or “ping <source DC name>”.

 3) Verify that the source domain controller is using a valid DNS server for DNS services, and that the source domain controller’s host record and CNAME record are correctly registered, using the DNS Enhanced version of DCDIAG.EXE available on http://www.microsoft.com/dns

  dcdiag /test:dns

 4) Verify that that this destination domain controller is using a valid DNS server for DNS services, by running the DNS Enhanced version of DCDIAG.EXE command on the console of the destination domain controller, as follows:

  dcdiag /test:dns

 5) For further analysis of DNS error failures see KB 824449:

http://support.microsoft.com/?kbid=824449

Additional Data

Error value:

 11004 The requested name is valid, but no data of the requested type was found.

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

I am very careful on servers to disable ALL unused network interfaces, lest they corrupt the domain. Here is why:

I once got called out on a job to give MS PSS support a hand onsite. Unusual I thought at the time, normally I ring PSS, not they ring me. Anyway, they had a rough time getting a client up and running and needed someone on the ground that could help sort through it.

When I got there the Windows 2000 Domain Controller and Exchange 2000 Server  were both very unhappy. The Exchange database was offline, corrupted, and the Domain had more errors in the event log than I had seen before.

After a bit of digging I found the problem. The Domain Controller had two network interfaces, a fairly common thing with server hardware. One of these interfaces had given itself a Private IP address, despite not being plugged in. Most of the Domain SRV records had been redirected to this private (and unusable) IP, making the Domain controller intermittently un-contactable. This had gone on for a significant period of time, before the other Domain Controller had lost sync and gone offline corrupted. The Exchange server hadn’t taken long after that to do similar.

Disabling the unused interface resulted in just one DNS registration, and presto, a happy AD DC again.

Recovering the Exchange Server was not so much fun. It turned out the “backups” were file level, not Information Store backups, so useless. The Information Store failed recovery with ESEUtil and ISInteg. I left PSS to sort that mess out.

I had seen similar behavior before with ISA boxes registering the incorrect interface. Now I am very careful to disable any unused interfaces, thus solving much DNS weirdness.

In theory the interface detection solves this, and I haven’t seen the problem in Server 2003, so maybe it was solved. I’ll keep being cautious.

Now this may be old news, but hey, it’s new to me.

I ran a DCDIAG /test:dns today and received an error

DNS server: 128.9.0.107 (b.root-servers.net.)
1 test failure on this DNS server
This is not a valid DNS server.
PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 128.9.0.107

Well it would appear that way back in 2004 the B Root Server had a change of IP Address as advised here. The old address was valid for some time but has since been de-commissioned, although I don’t know when exactly.

It’s no biggie, the other servers respond, everything runs as normal. It probably results in a touch more Internet traffic, but with all the Paris Hilton upskirt bandwidth I doubt it matters that much.

My question is, surely, this, of all the Critical Updates MS pushes out with WSUS, would be worthy of a Microsoft Update? Three years, but not as urgent as the “Critical” Windows Genuine Advantage. I guess it’s not critical for their bottom line.

In the meantime I think I’ll update some Root Server lists.

Lets say you have a server – MAILSERVER1

And you rebuild it for some reason. It’s a clean rebuild. As part of this rebuild you delete the Computer Account from AD. When you add the computer to the domain again, a new computer account is created.

BUT – if you have “Only Secure Updates” enabled in DNS, the new computer account doesn’t have permission to modify or overwrite the existing DNS entries. You’ll get an Event ID 11166 on boot up of the new server from DnsApi in it’s System Event Log. It’s only a Warning, not an Error, but the consequences could be significant. In my case Exchange Auth kept failing, despite logging no other errors in the event log. Don’t forget this applies to the PTR or Reverse lookup as well.

The simple solution is to delete the DNS records manually, then run IPCONFIG /refreshdns – and presto, all will be good.

The Event Log will say something like 

The system failed to register host (A) resource records (RRs) for network adapter
with settings:

   Adapter Name : {A7648FC7-7952-4AB5-9670-20E84EE3D8A8}
   Host Name : ***srv012
   Primary Domain Suffix : somewhere.com
   DNS server list :
         10.1.2.2, 10.1.1.2
   Sent update to server : 10.1.2.2
   IP Address(es) :
     10.1.2.10

 The reason the system could not register these RRs was because of a security related problem. The cause of this could be (a) your computer does not have permissions to register and update the specific DNS domain name set for this adapter, or (b) there might have been a problem negotiating valid credentials with the DNS server during the processing of the update request.

 You can manually retry DNS registration of the network adapter and its settings by typing “ipconfig /registerdns” at the command prompt. If problems still persist, contact your DNS server or network systems administrator. For specific error code, see the record data displayed below.

 It’s tough for media companies these days. We all hear about terrorism piracy of Movies and Music, and how it’s destroying the world.

Well I hear a rumor that now it’s moved to books. If you for example were stuck on a remote island with no access to external print media, then it wouldn’t be surprising that you found this floating round.

Reading books on a PC or handheld device just isn’t relaxing. Luckily Adobe has a “print in booklet” function, allowing a novel to be broken into manageable booklets.

It even appeared within a few days of publication, meaning someone put a lot of work into OCR. The formatting and all is correct, although the OCR errors in spelling increase toward the end, I guess they were in a hurry.

Not at I would ever participate or support such an immoral act. It’s just entertaining what you find in a 3rd world country that can’t afford to make a rich person richer.

Of course I did what any good law abiding person would do and immediately burnt the books.

Network Attached Storage – hey that sounds pretty cool. That should be  kinda like iSCSI? Ahh – no. NAS is the buzzword for what used to be known when I was a young boy as a File Server.

WOW – a real file server? yep, it’s that astounding. Somehow I have trouble getting all excited here. File servers have been round for a while now. NAS boxes come with an OS installed, and the discs on some type of RAID. I’m still not excited. 

I just can’t fathom the value proposition here.  Discs cost you the same amount weather you buy them in a NAS box or a File Server. The base hardware costs about the same, or if you save money it’s cheap junk. The OS costs you the same OEM or in the File Server.

If you get a Linux based one you have no NTFS permissions and it runs SAMBA. You may as well not bother with Domain at all – hey, there’s some less costs if you don’t need domain controllers.

Either way, Linux or Windows, they didn’t intend you to screw with the OS too much, so running AV, Backup agents and Updates can be interesting from a support perspective.

“But you can install your Exchange Databases on it” – well, yes you can. Same as you can install them on any file server. And get crap performance. 1GBit Ethernet is 3.5 times slower than 320MByte SCSI channels. I’ll stick with local SCSI thanks, at least I know the discs are dedicated.

So it’s a box on the network running SMB. That’ll definitely revolutionize the world.  I think I’ll just stick to throwing more discs at my current file servers. 

I’ve been playing with sat dishes here and there and every time I see a Fiberglass one the thought keeps occurring – how does something radio transparent reflect radio waves?

I had a few theories ranging from

• Metalised Paint
• Metalised Gel-coat
• Metal Fibre reinforced glass
• Metal Impregnated resin
• Foil Layers
• Wire Mesh

I had the opportunity to drill a water drain hole in one today and the answer became obvious (at least for the Prodelin brand dishes)

There is a fine wire mesh similar to fly-screen under the gel-coat.  It is very fine aperture to cope with the GHz frequencies involved. Hopefully it’s stainless, it looks fairly silver, so it wont rust from the edges in.

So when you are cleaning your fiberglass dish of the mould they seem to accumulate – you don’t have to overly worry about abrading the gelcoat. The mesh layer is reasonably well protected.

Another question answered. 

I spend most of my time visiting different sites implementing projects and sorting out problems. One thing that never ceases to amaze me is the huge plethora of file shares at most of these sites. It’s like having a file server means you have to map everything you can. It makes life far more confusing than it needs to be.

There is no “backup” tool for share configurations when performing DR on a file server. Ideally for my DR I want to be able to restore the files and that’s it, not worry about the server configuration. My File Servers don’t run any app’s, they do SMB and that’s it. All other functions are run on an application server. Print Serving runs on a VM.

The large number of shares generally equates to a large and complex login script that decides what to map to where. This makes file references different across the company, confusing users. It also makes logins slow (and often involve KIX – yech)

Try this for an idea

Run a single Domain DFS Root.
Have links for:

1. Users Home Drives (one link per server/site)
2. Software Deployment (one link – it’s replicated)
3. Company Data (may be per site depending on structure)

Map the Home drives and the Company Data shares. Presto, quick simple login for all. The structure is kept in AD, so it replicated and safe. DFS-R get’s copies of data where it needs to be efficiently. You file server only needs three or four shares to keep everything happy.

If you link the mappings to intermdiate links, as opposed to end targets, then the cleint PC’s never connect to all the remote file servers. Your roaming uses connect to the closest root and mobile users don’t get bogged down.

It gets a little more complex as you manage replicated vs non replicated data between sites, but DFS is perfect for this. The single root approach is far closer to the Internet that people are familiar with, as opposed to knowing which servers and shares things are on. Servers change, data structures should last longer than that.

There is a touch more complexity in planning, but operationally from a user and server management perspective – it’s far simpler. You login speeds are dramitally improved and roaming users are not impacted. All you need to do is organise.