In Exchange 12 (“E12”), we have focused our public API story on:
Web Services for accessing information stored on the server
Managed Agents for processing mail flowing through the serve...
Updated Jul 01, 2019
Version 2.0
Blog Post
Thank you Vivek, seriously. It is good to see you guys out here blogging and taking the questions and responding to them.
I just have years of frustration built up from working with Exchange and trying to make it work smoother or better in large environments (150k mailboxes+ mostly). I have been in the meetings where we were promised something would be all better in the next version and well, it might be, but not for any of the circumstances we had specifically described. The WMI mailbox reconnect was a perfect example. On the flip side I have been in meetings where a fix is finally promised and it actually gets delivered, the DSACCESS supplying GCs to clients based on the domain of the client is a perfect example there. It was extremely painful for me to fight for that and took months, but once you said you would fix it, it got fixed, it just came out in SP2 which is what was promised in 3/2004.
I fully admit I haven't seen the new version, I hope to see the docs for the SDK fairly soon so I can start sniffing out what I think could be the holes so they can be further tested. It is difficult to just test things in hopes that you find something that is going to really be painful in a 200k mailbox org. You just sort of have to think of the tasks and how they would be accomplished.
I have high hopes for the new edition, I hope it is everything that is forecast and more. I do have a concerned spot though already in terms of how that info retrieval will work.
I just can't visualize pulling all of that data across the network from a loaded Exchange server and plucking out what you need at the client and it being very efficient when you need just some small piece of info for every mailbox. I would think of it like needing the whenChanged attribute of every object in a domain and having to retrieve every attribute and throwing them away and keeping just whenChanged. In a smallish environment of ~7400 objects you are talking ~2 seconds vs ~25 seconds and ~700KB vs ~17MB. A lot of waste there. Just think if every query to AD required you to return all info about every object you returned and it was up to Exchange to filter out what it really needed? I expect you guys would be jumping up and down saying this is insane, we can't be performant in an environment like this!
Anyway, I will be out in Redmond next week for the MVP summit, hopefully you guys will be putting on a dog and pony show showing this stuff off and not just to the Exchange MVPs. The DS MVPs mostly seem to be involved with Exchange in some way or another as well. I would be impressed to see 10-15 non-clustered Exchange 12 servers running out of EEC fully loaded up with say 5k users a machine with simulated load of about 3500-4000 users and then "quickly" pulling some piece of data about each mailbox from all mailboxes across the WAN. Not asking for much am I?
take care, joe
I just have years of frustration built up from working with Exchange and trying to make it work smoother or better in large environments (150k mailboxes+ mostly). I have been in the meetings where we were promised something would be all better in the next version and well, it might be, but not for any of the circumstances we had specifically described. The WMI mailbox reconnect was a perfect example. On the flip side I have been in meetings where a fix is finally promised and it actually gets delivered, the DSACCESS supplying GCs to clients based on the domain of the client is a perfect example there. It was extremely painful for me to fight for that and took months, but once you said you would fix it, it got fixed, it just came out in SP2 which is what was promised in 3/2004.
I fully admit I haven't seen the new version, I hope to see the docs for the SDK fairly soon so I can start sniffing out what I think could be the holes so they can be further tested. It is difficult to just test things in hopes that you find something that is going to really be painful in a 200k mailbox org. You just sort of have to think of the tasks and how they would be accomplished.
I have high hopes for the new edition, I hope it is everything that is forecast and more. I do have a concerned spot though already in terms of how that info retrieval will work.
I just can't visualize pulling all of that data across the network from a loaded Exchange server and plucking out what you need at the client and it being very efficient when you need just some small piece of info for every mailbox. I would think of it like needing the whenChanged attribute of every object in a domain and having to retrieve every attribute and throwing them away and keeping just whenChanged. In a smallish environment of ~7400 objects you are talking ~2 seconds vs ~25 seconds and ~700KB vs ~17MB. A lot of waste there. Just think if every query to AD required you to return all info about every object you returned and it was up to Exchange to filter out what it really needed? I expect you guys would be jumping up and down saying this is insane, we can't be performant in an environment like this!
Anyway, I will be out in Redmond next week for the MVP summit, hopefully you guys will be putting on a dog and pony show showing this stuff off and not just to the Exchange MVPs. The DS MVPs mostly seem to be involved with Exchange in some way or another as well. I would be impressed to see 10-15 non-clustered Exchange 12 servers running out of EEC fully loaded up with say 5k users a machine with simulated load of about 3500-4000 users and then "quickly" pulling some piece of data about each mailbox from all mailboxes across the WAN. Not asking for much am I?
take care, joe