Your terminology "local account" isn't familiar to me. I think you're talking about Outlook creating the user's MAPI profile-- a set of registry keys and values that control how / where Outlook looks for the user's mailbox.
You're already seeing a fairly streamlined user experience as compared to previous versions of Outlook. The auto-discovery functionality in Outlook 2010 and Exchange 2007 make the setup a matter of just a few clicks.
The "Save and Send" functionality sounds like it's doing a poor job of detecting that the user's MAPI profile hasn't been initialized. That's depressingly typical behavior and, while I understand that you want the users to have a very "clean" experience w/o having Outlook open up and write a MAPI profile to the registry it's going to be difficult to get what you're looking for.
Personally I use Roaming User Profiles such that the user's MAPI profile "follows" them in their registry. This certainly isn't a minor undertaking to implement, but does create a situation in which Outlook "knows" where the user's mailbox is on each machine they use (and they only ever see a single "first run" experience).
The Office Customization Tool that you describes in your comment isn't going to be helpful, I would strongly suspect, because that tool doesn't create the user's MAPI profile-- it just specifies the defaults that will be populated into it when they run Outlook for the first time. Since the "Save and Send" functionality isn't detecting that no MAPI profile is configured and firing up Outlook to create the profile using the Office Customization Tool wouldn't be helpful.
You could, potentially, write a script to run on "Startup" that would check the registry for a default MAPI profile (looking for the presence of a "DefaultProfile" value at "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles" is a simplistic way to do that) and, if it's not there, start Outlook to force the user to complete the MAPI profile setup process. Personally I'd find that irritating but it's a possibility.
Edit:
The MAPI profile is in the user's registry. Roaming User Profiles makes the user's registry (and a host of other things) "follow" them between machines, so the MAPI profile will "follow" them w/o any special configuration.
Implementing Roaming User Profiles, though, isn't a "gee, let's do this today" kind of implementation (to get it right). You need to understand how the feature works and how it might interact with other features (like Folder Redirection). You also need to assure that you have good network connectivity to support the feature because it's notorious about performing poorly on latent or "lossy" connections.
You can find some discussion about Roaming User Profiles here:
- Roaming Profiles: Best Practices
- Difference between Roaming Profiles and Profile Redirection
- http://technet.microsoft.com/en-us/library/cc766489(WS.10).aspx
Best Answer
Yes, I've seen this - your clients may be also running OCS at login, or some other software that connects to the same MAPI profile; maybe some AV software, or other Outlook addon that starts up before Outlook itself.
That's my guess. You could run ProcMon from Sysinternals and see what's opening the OST/PST for the user's MAPI profile before Outlook does.
Run Procmon as soon as you login, with a filter for Path contains .OST (or .PST, depending on how you setup your clients.) See what processes, if any, have a handle open to the user's OST file. Seeing an open handle on the OST file is, IME, a decent proxy for having a MAPI connection.