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
- DeletedI work with a lot of different customers, ranging from 20 to 5000+ employees, and they all react strongly to having to use two different admin consoles for Exchange and AD.
One of Exchange's strongest point is it's tight AD integration, and therefore it's just wrong that you can't manage mailboxes directly from ADUC.
Another thing I miss is the ability to limit connections to POP and IMAP based on IP's. Lots of customers have older applikations that don't support secure POP or IMAP, so I've limited POP/IMAP access to specific IP's.
Thanks for a great blog! :) - DeletedHi guys,
I too, have been reading this for a long time and your openness and the way you conduct this site is a testament to the team. Your products are great. Haven't taken the step to 2007 yet but will soon.
One thing I'd like to ask, even though this is probably the wrong place is what the heck is going on with the IMF Updates lately? There is no way they are being released on a 2 week schedule as originally stated. We are drowning in spam but without the updates it's impossible.
Cheers from Oz.... - DeletedThanks for the opportunity to speak on this topic.
I agree with many of the comments here.
We have a highly distributed Admin model with central Exchange Servers. We look after the servers and users are managed by their own admins.
Our biggest issue is a perception of a step backwards with many of the features of Exchange 2007. I understand there are probably extremely good technical reasons for these changes but they don't look good to us.
Examples are:
* Attributes no longer visible in ADUC. In Exchange 2003 all the admins in our org can use ADUC to look at (and manage) user properties. Now simple things like secondary SMTP addresses can't be seen in ADUC. A new GUI or powershell (not appropriate!) is required.
* Delegated control. Another tool? Powershell? Assigning mailbox rights requires God level access to Exchange.
* Active Directory OU based functions/features. one exmaple being our use of many dynamic DLs built around areas of the org that are split in the directory into different OUs. Eg. All Finance Staff are under OU=Finance ... All other user properties can be different between users, such as office title, phone, building, department even. Now in ex2007 that type of DL looks like it only accepts address book property attributes being equal to something. We also have dynamic dls for "all users on server xyz" .... how to now?
* Public Folders. gone then back again, partly. Can you access them from OWA? manage them from a GUI. propagate permissions? Even with SP1 management isn't back in the Exchange GUI it is a separate one right?
* ADUC. Has to be mentioned twice sorry. Moving away from it looks like a step backwards. If it is a property display issue with the dialog boxes and the schema will Win 2008 AD bring it back?
cheers - DeletedHonestly, I am going to stick with my Exchange 2003 servers (I have 48 of them) until all of this nonsense gets sorted out. All benefits of 64-bit computing aside, I have to throw out the baby with the bathwater to get Exchange 2007 rolled out in my enterprise. Not worth the expense, hardware-wise or labour-wise if you ask me.
my criticisms:
- crappy upgrade path (see above), I have complained ad nauseum about it so I will leave it at that.
- de-integration of ADUC. You had a wonderful thing going and then you change it. *meh*
- de-guification of major features. (see above)
It is almost like you intentionally obfuscated the administration of Exchange to foster and protect the jobs of the "Exchange administrator". Not that I am against a competent product managed by competent people, but our jobs are being crammed into ever-so-tighter schedules and I for one would like to see EASIER and QUICKER to use products rather than ones with some sort of "paradigm shift" to command-line interactivity.
With my bevy of Unix (and Linux) servers, I have an intrinsic LOVE of the command-line. That is the beauty and simplicity of Unix and Unix-like operating systems. Windows, however, is NOT Unix and is NOT a command-line operating system. It is a graphical user interface with a very large and complex engine running underneath. Windows users expect (and indeed sometimes REQUIRE) a GUI interface to interact with it. By shoehorning in all of this command-line interactivity, regardless of merit, you are needlessly complicating things for the people I am, in the end, going to have train to support it.
So, like I said...I'll be sticking with Exchange 2003 for now. Thank you very much. - DeletedFirst of all there is a hell of a lot that is great with Exchange 2007 when you include SP1. My hats off to you for making a great product.
If you're looking for crtiticism, then I'll keep it to only that. Powershell is awesome and I didn't understand its strength until attending the Exchange Customer IT Fellowship program here in Redmond last week and this. But (there is always one isn't there?)... your typical every day Small-Mid sized business Windows admin is not going to have time to learn a lot of these cmdlets not available through the GUI.
I think the GUI should retain at least the same command set the E2K3 tools had and then if you want to split it off from there so be it.
Personally I work in a highly decentralized environment with centralized Exchange services. We have hundreds of site-level OU admins across our org who I can tell right now will never be able to learn powershell. They either lack the skill or the will to learn something new. I can hear it now "then why were they hired?"... well, why were most people in gov't hired? They probably know someone or have been there for years and are union boys and gals. These are folks who simplly need to be able to create mailboxes, check the current size of their users' mailboxes, add secondary SMTP addresses, provision users through ADUC, and other low level (or high I guess, depends on your definition) functions.
A lot of these tasks are now only doable through Powershell or the separate Exchange Management Console. I'm going to have to write scripts for them to run or spend a lot of time training them. Giving them scripts isn't too bad, but I'm afraid there is far more possibility for them to play around and instead of mucking up a couple user mailboxes, they'll affect hundreds instead.
AD and Exchange were joined so nicely before and to me it is a shame to see them becoming separate again. Please do not assume all organizations have seperate AD and Exchange departments. Give us the ability to keep it the way it was if we so choose it.
If it is of any kind of help, our profile is a 34k+ mailbox org growing on pace to be over 40k very soon. We have a small centralized Exchang/AD team (8 people including managers) and then a bajillion site level admins out in the field doing front-line user and file/print/db support and whatever else their agencies need. - DeletedAgree with these comments:
* Add the ability to manage Exchange functions back into ADUC. It's hard to tell support that they have to go back to two utilities to do their jobs. <note: I understand why you made a separate tool, to separate admin functions, but why does a separate tool have to preclude the use of an integrated too, too?>
* The ability to see mailbox sizes in the GUI view of recipients, or store database sizes would be good too. Anything to help me balance several CCR clusters is helpful.
* An easier to learn message tracking system. Oh how I long for Ex2k3 message tracking. I know, I'm just not use to it yet.
* The cert process is ridiculous- even the example you posted had syntax errors. If you can't get it right, how in the world can a jack-of-all-trades, overworked admin?
My two biggest frustrations are:
1. That you opted to build out Powershell/EMS completely while also choosing to remove critical parts of the GUI. It's fine to add features (like EMS), but doing so at the expense of features that we've used for years is a BAD idea. Many admins are now collecting EMS commands in notepad files. Is this really a step forward? Imagine of the Office team decided it was too complicted to code the Print function into Word 2007 and just had users enter a Powershell command to print documents...
2. Even with SP1 installed, there seems to be a massive memory leak, at least in a single-server environment. I'm waiting on hold with PSS to get this sorted out right now (and yes, I have the aforementioned hotfix installed).
3. The install scripts were not prepared well at all. For example, the single label domain issue should have been caught at install, and the hoops I had to go through to get SP1 installed were nothing short of atrocious: Every time the install failed a complete reboot was required and once when it failed it left many services set to disabled.
I've been using Exchange since 5.5 and this version isBY FAR the most unstable, difficult to admin, buggy version, and we're over a year out from RTM now. Are the problems and feature gaps ever going to get fixed, or will this be like Vista: The version everyone tries to avoid while waiting for the next one? - DeletedIt would be great to customise the OWA login page text (I know we can customise the colours/pictures).
In OWA 2003 we could directly edit the text in the ASP file to customise the text whereas it they are now embeded within a strings.dll file
Cheers Guys - DeletedHow about OWA calendar printing options? The current method of printing calendars in OWA 2007 is quite limited and lacking in functionality.
- DeletedEgon,
Please see the following page for page file requirements on Exchange 2007 servers:
http://technet.microsoft.com/en-us/library/aa996719.aspx
On related note - Store.exe will use as much memory as possible on the Exchange 2007 server to keep as much in the cache, which is much faster than going to the disk (paging). - DeletedThe Store.exe on my Exchange 2007 uses to much Memory. On a System with 16 GB RAM and no Pagefile i have Out of Memory Errors...