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.

We have a couple of clients with an unusual setup for Outlook. They make use of our hosted Exchange service for Calendars and Contacts collaboration but, their email is on a GMail account and access in Outlook via POP.

The admin assistants for these high level CEOs put appointments into their boss' calendar. But, the shared calendars would refresh very slowly when paged to from another section of Outlook.

If you are having this kind of problem with a POP/Exchange hybrid account, the solution is available in Outlook 2007: Configure separate data files for each account.

This was not possible in previous versions of Outlook (XP, 2003, etc) but, works a treat in 2007. The Exchange account should use a .OST cache file, as usual. The Gmail account should use a .PST.

Here's how:

Configure both accounts in the usual way in Outlook:

Highlight the Gmail (or other POP) account and click the "Change Folder..." button.

You will get a dialogue box asking you which folder. Click the "New Outlook Data File..." button.

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.

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.

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...

I wanted to give back to the generous community of technical bloggers, forum users, and webmasters who post amazing and accurate answers to system administration problems and questions.
I wouldn't be half as efficient at my job if it weren't for all these largely anonymous benefactors (and the almighty Google, of course.)
I plan to post decently organized instructions and recipes as I come across them in my work as a network engineer.
Sometimes I piece together the answer I need from several KB articles, forum posts, and websites. I've always thought it would be nice to organize the solutions so that all the information is in one place.
I'm hoping that someone will come across just the answer they need in BitWrench here and have the same great flood of relief fill their heart as it does mine when I find a solution.