I recently (hopefully recently, my last post took two years to get published so I'm not sure when this one will go out, LOL) posted one of my typical light-hearted looks into life at Microsoft (it was about how office space is allocated, read it here). Although it was irrelevant to virtually everything, it elicited many interesting responses, including people complaining (I think) about us having it too good here. No argument there. Actually, I was intentionally portraying the situation in a negative light so as not to upset everyone too much. In reality, we all have 1000 square foot corner window offices (our office buildings were designed by MC Escher) that overlook a lake or mountains (our choice), with a private bathroom, a fold out bed for nap time, and a full service kitchen. But never mind that. There were also many comments on the feature set of Exchange 2007 (rather irrelevant to the pointless topic, but important nevertheless). They were mostly not liking certain feature take-backs in the release, particularly around the administrative GUI. I just want everyone to know that despite the light tone here, we do take these comments seriously. Let me assure you that the discussion that my post prompted generated many a transaction log on our corporate Exchange servers!! Some of you that have been reading our blog for a long time may have noticed that we have taken a very open position regarding the comments that we get on our blog posts. I believe that there were only 2 or 3 cases when we deleted a comment and that was because of some really inappropriate language. We want to keep your comments there, both positive and negative. We read every single one of them and respond to many. We do want to encourage you to post your opinions and ideas, but we do have ask something: if there is an area that is very upsetting to you or where you think we made a mistake, we ask that you would offer criticism about the product, and not the people who work on it. Also, since we actively look to these comments as evidence to make potential changes in our products, we again ask that you would provide specific, actionable feedback on our product. In other words, please explain what it is that bothers you and why it bothers you. What are you trying to accomplish that you can't? Sometimes the comments are obvious (we totally and completely get it that you need more GUI and it's unfortunate we weren't able to get as much of it in to E2K7 RTM as we'd hoped, but we hope that SP1 works better for you there), but sometimes they are not, so the more you explain your user scenario, the better a chance we'll be able to eventually do something about it. In closing, I'd just like to point out the obvious that every product that has ever shipped anywhere has had to make trade-offs between shipping on time, shipping with quality, and shipping with the right features. For Exchange 2007, we debated long and hard about features that we would ship. We had to balance investments that we wanted to make into the Exchange code base to allow for future innovation (would people be interested in a description of those architectural bets? Or if we posted it, would we just get more "you should have done <my feature foo>" instead? :), feature cuts we felt we had to make to get the quality we wanted to ship with and the timeline we felt it needed to ship in. We knew some of the cuts would be painful, and we have addressed many of the larger issues in SP1 (some posts on this coming your way, by the way!). Judging from the early success of Exchange 2007 sales, the many positive reviews we've garnered, and most customer feedback, we seem to have made some pretty good choices here. But obviously - not perfect. We always need to try to do better. I look forward to the responses this post may receive, and rest assured there are lots of people in Exchange who will be paying attention to them, as with all our posts on this blog. Thank you for coming back and caring enough to comment! - Jon Avner, Nino Bilic
Blog Post
60 Comments
- DeletedJust thought of another thing. Integrate Message Classifications into IIS and give it a URL field in Autodiscover and work with the ISA team to create a /path/* for this URL. It's pretty ridiculous having to distribute the XML file to every single client and modifying the registry settings for this. We should be able to enable message classifications through some GPO (even though we can manually add that into a GPO, but still...). Outlook should then be able to connect to Autodiscover and get the URL for the message classification XML file.
- DeletedCan we please get mailbox list (per mail store) and last logon back in the GUI without having to go through making a bunch of filters? We use it for troublehooting rather often in 2003 and having to resort to powershell in this case isn't optimal (for us at least...).
Thank you. - DeletedLee,
See if this helps: http://blogs.msdn.com/dgoldman/archive/2007/02/08/oab-generation-on-a-cluster-server-fails-with-event-id-9395-or-9396.aspx - DeletedHere's one I just ran across that I can't believe is true. You can only generate the OAB on one specific server in a CCR cluster. If you fail over, OAB generation fails until you fail back or alter registry settings
Is this really true?!?!
See here..
http://technet.microsoft.com/en-us/library/bb266910(EXCHG.80).aspx
please make this redundant...soon, or allow me to run it on another server type, such as Hub. - DeletedE12 has great new features - SCR/LCR/CCR are alone worth the price of admission. But I'll chime in here with a few gripes as well. :)
1. As others have mentioned, the SSL certificate "procedure" is torture. I installed a 3rd party certificate in my test environment and when it came time to renew it I put it off for over a month because I remembered how painful it was the first time around and I knew I'd have to spend at least 30 minutes just refreshing myself on the steps. Even though this was only about a month ago if I were to do it again tomorrow I'd spend the same 30 minutes doing another mental reboot.
2. I like PowerShell and learn more about it every day. I think using it as the basis for Exchange management was a great idea, but I feel like I have to drop into it far too often to perform mudane tasks. I don't like being able to set some SCL levels in the GUI, for example, but to set the Store Junk SCL threshold on a mailbox, I have to drop into PowerShell. Why? If 100% of Exchange tasks are available in PowerShell, 99.9% of those tasks should be present in the GUI. The remaining 0.1% should be so esoteric that I only have to do them once in a blue moon.
(Before I go on, a slight diatribe on PowerShell in general. I think the main problem with the adoption of PowerShell, or the resistance to it if you will, is a simple matter of history. As Windows administrators we're all used to doing everything in a GUI. Cisco administrators would say the same thing as they've been configuring their gear via telnet/SSH for years. If someone gave them a GUI it would feel foreign. For most Windows administrators, the opposite is true.)
3. As others have mentioned, the separation of AD and Exchange tasks as well as the removal of the functionality from ADUC makes sense from a delegation of management perspective, but for a good majority of SMBs the AD folks are also the Exchange folks. Actually, I'd like to see MORE integration of MS and 3rd-party utilities into AD; it would be so nice to tell the HelpDesk folks to "go to ADUC, click on <USER> and go to <TAB> for <TASK>" instead of "go to <THIS TOOL>, then click this, etc."
4. Public Folders. These poor things are the "middle child" of Microsoft collaboration tools - better than a file share but not as good as SharePoint. In our organization they're very handy, however. We don't have the internal knowledge or (frankly) the need for a SharePoint installation. Our users have a strong grasp of Outlook so Public Folders come naturally to them. We also use them as group fax inboxes and group "mailboxes." They might not be as sophisticated as SharePoint but I for one will be sorry to see them go. Utill that day comes I hope that they don't become an afterthought in the Exchange management tools.
5. Now that the Exchange and RTC Groups are under the "Unified Communications" umbrella, I fear that the next versions of OCS and Exchange will be merged into one product with several roles as E12 is now. While I like the Exchange-OCS-AD integration, many SMBs will likely not be able to go "full OCS" for several years due to the complexity of OCS deployment. I'd hate to see Exchange become more complex then necessary.
6. Any additional improvements to make clustering failover/failback as painless as possible for DR/BC scenarios are always welcome.
7. Regarding the EHLO Blog, I'd love to see more "internal/how Exchange works under-the-hood" posts. Actually, you folks should write an "Exchange Internals" book - it would look great next to my copies of "Inside SQL Server" and "Windows Internals." Please? :)
A sincere "THANK YOU!" to all the members of the Exchange Team for a great blog and for listening to us customers! - DeletedI agree- removing the mailbox items and sizes from the GUI was a poor choice. Now instead of a few clicks to get the list of mailboxes sorted by size, I run a long cmdlet (212 characters), that pipes to a CSV, then import the CSV into Excel and sort. For a quick report I struggle sto see how this is any sort of improvement, as it takes significantly longer.
In case anyone is interested, here is the cmdlet I use (careful of wrap):
Get-MailboxStatistics -Database "mailbox database" | Sort @{expression="totalitemsize";descending=$true} | select DisplayName, @{expression={$_.totalitemsize.value.ToMB()}}, itemcount | Export-csv c:mbreport.csv
L - DeletedHere is a suggestion that I feel would benefit everyone.
I would like to be able to use group permissions to control access to auto attendants.
I would also like a standalone GUI based tool so that users can manage the recordings on their auto attendants. With the amount of auto attendants we need to create, managing them will be an administrative nightmare because people are always updating their recordings. - Deleted1. Outbound Faxing
2. Certificate Generator for SANs that will place certificate names in the proper order depending on needs
3. Better/more migration tools that will assist in making it easier for us to migrate to Exchange 2007.
4. Mailbox Items and Size in GUI.
5. Better Message Tracking System
6. Better support for configuring Autodiscover service in the EMC. Both for InternalURL and ExternalURL for ALL services including the ability to enable SSL for these services and their authentication settings.
7. Owa premium for Firefox
8. Don't release an incomplete product. Almost everybody I talk to agrees RTM was released too early. Functions that were used in Exchange 2003 should not have been postponed to 2007 SP1. If needed, push back the RTM date.
9. AND PLEASE.... allow us to set calendar permissions via a GPO or via some other method. For instance, in our organization, we have Default - Reviewer so everybody can view each other's calendar. And when I said better migration tools, that means the functionality to be able to share this cross-forest as well, and not just free/busy.
10. Better functionality for sharing free/busy and calendar data with newer versions of Exchange. I'm assuming this will be better in Exchange 14 due to it most likely using Availability service. - DeletedArchiving.... please for all that is holy try to work a real archiving, secondary storage, legal discover piece into the product. Many of us are forced to spend ungodly amounts of money on Symantec & EMC products which can be nightmares to install and administer becuase there is no built in way to do legal discoveries across multiple mailboxes, enforce compliance in a meaningful way, nor a way to shove old data off onto another disk media type for long-term storage.
Do it for Santa Clause!
Thank you! :) - DeletedWhere is the MS Press Resource Kit book for Exchange 2007? Your product has been out for over a year, yet you have not released an Exchange 2007 Resource Kit book.