Issues between Exchange 2003 and Outlook 2010

It looks like there are some issues between Exchange 2003 and Outlook 2010 that don’t allow internal users to send to each other. From what I’ve read it’s only internal users and Exchange 2003 that is having this problem. A few people said http://support.microsoft.com/kb/820379 fix their issue but it didn’t work for me.

I went to the same registry path that the article specifies and increased the NonMAPINamedPropsQuote data to a higher number. I changed it from 8192 to 16000 and it is working now. I picked that number at random and I’m not sure of all the possible ramifications from this but it looks like a safe change. You also need to dismount and remount the store for this to take effect.

Why .com is a bad choice for a Windows Active Directory domain name.

(or, How to choose an AD domain name.)

We run into this issue from time to time when a Windows domain has been set up by an inexperienced admin. It seems sensible and intuitive on the surface to have your internal domain name match your internet/website domain.

For example: your website is www.mycompany.com and you set up your Windows Active Directory domain to match as www.mycompany.com.

I myself thought this was a good idea when first starting out with Active Directory.
It's a terrible idea and here's why:

First, every machine in your domain should be pointed solely at your domain controller(s) for DNS resolution. In addition, your Domain controllers should have forwarding entries to your ISPs DNS servers to take care of internet name resolution.

So, what happens when you enter an address like www.mycompany.com and your internal and external domain names match?
Your workstation asks the domain controller for the server www.mycompany.com.

If your internal domain ends in mycompany.com the domain controller looks for that A record in it's forward lookup zone, doesn't find it, and sends back a 'host does not exist error'.

If your internal domain doesn't end in mycompany.com but, ends in mycompany.local (or any other ending you care to use), the DC/DNS server realizes immediately that it doesn't have the domain info and sends the resolution request to the configured 'forwarding' servers for resolution. The forwarding server will then reply with the correct IP info and your application will continue on it's merry way.

Obviously, the second case is preferable because it avoids an error condition.

How do you solve this name resolution problem without changing your internal domain name?
If you're already stuck with a public domain name but, need to resolve external servers, you can make an entry for 'www' in your forward lookup zone that points to your actual, external, internet-facing web server. (You will also have to make an entry for any other external servers you may need: smtp, pop, imap, mail, etc.)

It also dangerously blurs the psychological and technical lines between two very different networks which have very different security and access requirements.

Additionally, not having matching internal/external domains removes the need to make internal DNS entries to refer to external servers. You can simply keep your internet-facing DNS entries where they belong, in your domain registrar or hosting company's DNS control panel.

There is a great advantage to having a very sharp and clear line drawn between your interal network and your publicly-available services. This line works best when it's both psychological and technical.

Here's corraboration from MS:
http://support.microsoft.com/kb/296250

All the best...
Chris Thompson
Network Engineer

Every business needs a domain!

In working with some really small businesses lately (3 to 4 computers) I've realized that, even at that size, having a domain is worthwhile. Synchronizing usernames and passwords on a workgroup and creating permissions can get time consuming. It really goes south when you try to implement some kind of regular password change!

The only argument against it is expense but, even if you run it on plain workstation hardware to reduce expense, it's worth it to have a domain controller on site. Running Server 2008 on a decent workstation is totally do-able in a small environment.
Having a Windows server/domain gives you management capabilities that will save the client money (and me pain) in both the short and long run, namely: Active Directory, VPN, DHCP, DNS, WSUS, Stable File and Print serving, Remote Web Workplace, and Group Policy.
In addition, if and when the client expands, the server will be ready to handle the extra connections (unlike WinXP which is limited to 10).
Just having an admin login to every workstation that is the same is worth the extra $700 or so.
When speaking to clients of this size in the future, I am definitely planning to push for a purchase of Server 2008 even if the hardware it runs on is not that great...