You've probably been seeing the news reports about E12 and wanting to know more. Well, the one-year anniversary of this blog is coming up on February 9th, and we thought that would be a good opportunity to give our readers a chance to ask us questions about Exchange 12. RTM is still quite a ways off and there are still many things we're working on, so we won't be able to answer everything (after all, you wouldn't want us to tell you one thing and have it change a month later :-), but we'll answer what we can. So if you have a question about Exchange12, add it as a comment to this post. We'll collect the questions for the next week, pick five or ten of them to respond to and we'll post the answers on February 9th. Happy blogoversary!
I think a lot of people are really interested to hear more about how the site/database replication/online standby (varies according to who has reported it!) is going to work.
Since I ask this everytime I talk to Microsoft developers :-), any news on when will the 32k server side rule limitation be resolved (not really an Exchange issue, but I always ask) andor are there any plans on changing how the rules work with OutlookExchange (using a differnt method such as seive filtering)?
Still waiting for XSO for Titanium. It's now 18 months late! Please say SOMETHING. If it's dead, say so. If it has been deferred to E12, say so. If Mindy Martin disappeared with all knowledge of it, just admit it!
<br>
<br>If we're not going to get full-featured, supported, remotable, managed API soon, then open up the MAPI interfaces for stuff like Search Folders. It's clear that there's a new folder in the store named Finder which Outlook is guarding for itself. Either update ExMerge to transfer this folder along with "Associated Folder Data" or else update Outlook to export/import the Finder properties (like the Rules Wizard can do with RWZ files) or else publish the API so a customer or ISV can do the job for you. How can you keep pretending MAPI/CDO is dead if you're not shipping a replacement and you keep enhancing MAPI for yourself? I'll bet you'll just abandon Search Folders in favor of a new Lookout-related Search strategy, but I wish you'd just say so, so that customers won't bother accumulating dead-end Search Folders.
<br>
<br>And PLEASE do NOT RTM E12 if the Release Notes are not finished, the core online help is not finished, and PSS is completely unprepared. If you have to shrinkwrap a single retail box to show at a launch conference which was scheduled months in advance, fine. But don't let code reach distribution if PSS has not been trained and the basic docs are months away from RTW.
Will there be an Active Directory upgrade requirement or any major changes in terms of AD requirements?
Will co-existence with Exchange 5.5 server environments be supported?
Will it be possible to use different postmaster SMTP addresses in a hosted Exchange scenario with multiple inbound SMTP domains (not always postmaster@<domain in default recipient policy>)?
What about making Exchange 12 more usable in federated environments, specifically environments where different administrative groups own their own domain and their own admin groups/routing groups, but collaborate (and subjegate) at a forest level.
What will happen to public folders in E12? Public Folder features haven't really be extended since MSX 5.5 and I think there is a clear move to WSS and SPPS at Microsoft regarding issues as working with documents and stuff like that.
Regards
Bernd
I personally would like to see Exchange support a more aggregated version of calendar, sort of "group-calendar" where it would be possible to gather entries from selected persons calendars and see which time-slots are still non-allocated in. (and not require explicit rights to review anyone's calendar)´
Kind of like expanded free-busy information in more accessible form, perhaps.
64-Bit support: Will it have AMD64/EMT64 support? If so what benefits will we get from it? (E.G. Larger DB Cache sizes, Additional 64-Bit register support,etc...)
Outlook Web access:
Support for Single Sign-on in a FE/BE Enviornment - constant annoyance for companies that integrate OWA into their portals as we cannot use FE/BE internally as it does not supported Integrated Authentication. Single Sign-On with HTTP compression - currently no way of doing this also handy for Intranet Sites especially in companies with remote sites over slow links.
Ability to supoprt More Storage Groups/DB's per server?
Mobile Active Sync/Mobile Devices - It currently uses SMS with puts wireless devices @ the mercy of carriers. Some carries have notoriously slow Email->SMS gateways any way of getting around this (Push Activesync?). How's about the ability to use a SMS/EMS/MMS phone was a wireless email/Pager... e.g. when a new mail arrives send a copy to the SMS/EMS/MMS enabled device. Wireless device provisioning (like Rim's BES 4.0)speaking the BES 4.0 having similar support for wireless device policies, encryption/security and wireless device termination would be nice.
Any Improvements to Clustering (# of supported users/cluster, Failover times)
Any sort of Built in HSM? E.G. Keep current data on Fast FC/SAN disk, keep "older" data on slower ATA/SAN disk?
Any new disaster recovery features, espically ones that help with remote site/SAN replication (log shipping?)
Oh well that's my wish list.. curious to see what everyone else posts.
Anyway to assign rights to a calendar by an AD group? If I have group A and each person wants to be able to view everyone's calendar in group A, then why can't I assign Group A the correct permission on the calendar?
Really would like to see Exchange adopt more open standards so that more features are not dependent on MAPI. Basically, the more Exchange can offer it's rich feature-sets to non-MS clients, the broader it's marketshare will be, and the greater it's adoption will be in diverse companies.
And of course we'd all like to know what caused Exchange end up not using the SQL DB. (i'm assuming time-to-market / development issues)
Will there be a new release of MAPI that comes in a redistributable package and that is 100% backwards compatible with all previous versions of Exchange MAPI and Outlook MAPI (well, at least those versions that are still supported by Microsoft)? Please? Pretty please?
I'm very interested in non-shared storage based clustering/failover. Possibly via log shipping?
Also, how about multiple public folder roots? how about NOT being forced to always open "all public folders"? (linking directly)... i know these are somewhat contradictory in nature, but the concept is still the same... i want multiple "roots" (either skipping the all pf's, or allowing multiple roots) easily accessible.
Also, on the note of PF... how about disabling the newsgroup pf?
how about custom outlook forms in OWA?
lastly, any way to maintain SIS when moving users to new server (since slipstreams aren't exactly supported... and upgrading isn't my favorite thing to do on a production server)?
2 features I would like to see in the next version of Exchange:
1- Exhance the anti-virus API so I can get the whole internet header in quanrantined messages.
All anti-virus 3rd party told me that this was a limitation of the current exchange API
2- Allow some EASY way to customize default system messages. I live in canada and I need to give email service in 2 languages. So far there is no easy way expect hacking some dll or deploying separate servers.
I hope we will exentually see some xml config files for that.
One more thing I little tidbit I'd love to see if you've done different. Some corporations like to limit some users to OWA only any changes to how to do this. Currently the only way to do so is to disable Client versions of MAPI server wide. ANy chance of this happening on an per-user basis? or chaning this way this is done so I don't have to devote a whole server to OWA only access?
I was thinking about re-creating single instance storage...
Assuming a server's got capacity to spare (regarding local resources anyway - CPU, RAM, disk i/o)... if the .edb were to contain an additional [hash] table, attachments could be given a hash value (not necessarily requiring a full scan either, perhaps only based on first 20 bytes, as you'll see in a moment)... the table would also include the location for each attachment. Doing this, if ever a user needed to be moved (between servers/storage groups/etc), or exmerge imported, a quick hash table could be used to determine LIKELY matches for single instance storage.
Clearly a unique identifier can't be used across all orgs/servers/etc, as the bandwidth in multiple-server environments would be overwhelming on such menial traffic... but using the contents as a base for the hash, with a lookup table for likely matches, if a match is found exch can scan each file completely to determine true SIS status or not.
I say this if for no other reason than to stress the importance of this. I maintain the exchange server at my company of 50 employees. Because of the nature of our email, we do not have quotas defined for any of our users. (To reduce wasted space i have an outlook GPO to always "ask user to remove anything from 'deleted items' upon exit"). As we look at upgrading to exchange 2003, I will be forced to look at our 10gb database with SIS ratio of 6 (AFTER upgrading from our 6gb exch5.5 store via exmerge, and loosing first round of SIS).
I've looked at archive copies, multiple servers, blah blah... our email is critical... it's going to take space on our servers (as opposed to workstations/laptops) anyway, and going to be part of our nightly offsite tape backup, and i'd rather it stay in a single-instance-storage container such as Exchange.
I would imagine such a scan would be easy to allow as an option, allowing administrators to choose whether it's a task worth burdoning on their servers... heck, if i had the option i might ONLY turn it on if i ever had to import data (via move mailbox wizard, or exmerge, or outlook importing via PST).
I´d like to have the possibility easiely to define new views to the GAL. For example the secretary - group only should have a Gal with Display names, Email-Adresses and Telephone numbers, the adminstrators should see more attributes (alias or prvate phone numbers).
PerfMon:Are there improvements to track Client Usage ?. Currently there is no way to find out, how a client uses the Exchange Server (Number of Accesses, Bytes transferred between Outlook/Exchange). With E2003/olk2003 you added a counte for RPCdelay. With POP3/IMAP4/RPCoverhTTP, i can use IISLogs to track down the usage per user.
IMF: Will there be a option to configure the SCL Level to move a messageto JunkMail per Store, per User or per group instead of "global".
ActiveSync: Inbox, calendar and contacts are not enough. What abouts tasks, gal etc. (I know thats more a PocketPC issue).
Store: 16 GBLimit. Get rid of that with E12 or the next E200/2003 Service Pack. Please increase it to a higher value (maybe 32GB, 60 GB or so) Even SmallBusiness needs more that 16GB storage. This limit is nos nearly 10 years unchanged :)
I just ran into the 32K limit for rules on the server - I have extensive rules set up in my standalone Outlook to admin email coming in from over 8 different accounts and pre-sort it into folders. The 32K limit whacked my number of rules at about 1/4 the number I have defined. Now I can clean up a few, and rename them to be shorter, but that's still not going to ge me down even to 1/2 my original number of rules. What a pain!
- Policy based definition of default mailbox folder permissions, e.g. Calender - default - reviewed
- Enhanced possibilities for the sender to track messages (not mail based!), for read, delivered, forwared to, replied,...
- Enhanced auditing capabilities
- GUI to customize quota messages :-)
- Improved inter-org Free/Busy replication (not MAPI based! preferred SMTP)
- Log shipping
- Smartcard authentication for OWA and Outlook with RPC over http (alternatives to basic authentication)
- Customizable global address list view (change shown columns, size of columns, ...), not sure if this is pure server or a MAPI limitation ...
- MSI based installation
- Extend CDOEXM
- Give CDOEX to bcc field
I have a couple questions. Will automatic Directory Access detection cross AD Site boundaries so they do not have to manually added in?
As for store size, I know they'll be some archiving built in but has there been discussions to allow customized Attachment Criteria (Types, size, age) to be compressed in the EDB and STM databases to help control store growth? I know they'll be a performance hit but Exchange has fast become I/O and Disk bound (not processor).
I see lots of good questions here, but where are the answers? Weren't they supposed to be posted feb 9th?
<br>
<br>Thanks for an excellent blog!
<br>David
Will there be a way to restrict certain groups or users within AD from receiving e-mail from specific SMTP relay servers? This has been an issue since the server that relays our Internet e-mail looks no different to Exchange than the server that relays our internally generated application e-mail.
