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
Hi Vivek, of the options presented, the only method that actually sounds like something I would consider for managing from a non-MS platform is direct update of AD since it does allow non-MS technologies to natively work with it. However, as you say, "This is not what we recommend to our customers" and depending on where you look now, you find that it may not be a supported mechanism to manage Exchange at all.
It seems silly for customers to have to write an interface to manage Exchange when you are in the process now of making changes to the management interfaces. It sounds like a good time to ask for and hopefully get, more flexibility in what you provide. At some point, you guys (Exchange Dev) need to realize that not everyone runs everything from Windows like many of the other groups are realizing. Look at the R2 offerings, how much of that is directly related to helping people interoperate amongst multiple platforms? You guys seem to be out of step with the rest of MS Dev. Also, it would suck for a customer to create an entire management interface only to have MS decide, well what we did in E12 was wrong, we are going to change it again. Most companies out there using your products are not software development houses.
While on the topic of modifying AD directly, if you guys intend to continue using AD for the backend store of info, Exchange needs to be smarter about checking validity of info before using it. As mentioned, it is possible to directly modify things so that means that AD is an untrusted source of data. The data needs to be validated before being used. Duplicate values, etc in AD shouldn't bunch Exchange up, it should run into it, validate it, and indicate that isn't good and then ignore it until it has been corrected. Again, it is a data source that resides outside the body of Exchange so, according to all secure programming practices, be considered untrusted and needs to be treated as such.
Also, Exchange/Outlook needs to either look at its own store or look at AD. This situation of looking in both places and doing things is a support quagmire. Permission and security is a great example, the mailbox ACL either needs to be in the store or it needs to be in AD, pick one. As well as how publicDelegates are handled. I previously ran into a great issue where Outlook would update the publicDelegates and the store piece would be cleared out but the AD Piece wouldn't and Outlook would show you that it was all fine, right up until someone could still send mail on behalf of someone else and no one could figure it out until they looked at AD directly instead of with Outlook. There are probably many folks out there right now with multi-domain Exchange deployments who look at outlook and see publicdelegates and think that is right when in fact, AD has additional folks as publicDelegates on those accounts.
Also, back to
"#5: Actually the monad way to do it is to get all the data back and select only what you need. For example: $stats = get-mailboxstatistics "domainuser"; $stats.LastLogonTime. Or you can do get-mailboxstatistics | select-object LastLogonTime. Either method will work."
Doesn't that seem a bit heavy if say you are looking to get the size of mailboxes for all users across an org of 200,000 mailboxes or even 2000 or list which users have mailboxes over x MB? You have to pull all info for all users and then throw it all away except for one small piece of info for all users.
It is a scaling issue. This stuff works fine in a lab with 2 exchange servers running with 50 mailboxes with unlimited network/cpu like I have in a home lab, but when you get to the real world the lack of imagination from MS in running large orgs comes to the forefront.
This is evident when you look at the current tools and how they only allow you to work within a single Org or the WMI providers that don't accept a domain and a userid or even the DNs being used since they point at people used to doing everything from the GUI which is generally not very efficient.
I am afraid we are turning in some silly limitations for others. If you have to return all info for a mailbox to get one or two pieces is how you intend to do it, you might as well tell people now in good docs how to build their own management interfaces that run on the exchange servers so they can write their own efficient mechanisms for doing things.
Again, what you have now even works fine in small companies, but MS is pushing to take over large companies and have huge email systems out there, I, being someone who works with companies on this stuff, would love to see it so I don't have to sweat blood to make it work well, the way that MS shows the CEOs and CIOs in brief look how cool we are displays.
Right now I am trying to figure out how to efficiently get a listing of all rules across all mailboxes in a 200k user org because of what appears to be a poor implementation of the rule "from a DL" which seems to have serious impact on Exchange servers because of the additional LDAP expansion queries that has to occur. You might think something like that wouldn't be too difficult. You would be wrong. If I had only 50 mailboxes, I could easily just go look myself, that stops working somewhere around several hundreds of mailboxes. Heck, the "from a DL" rule wouldn't even be an issue in a 50 mailbox org, the server could easily handle that additional expansion work again.... Again... scale issues and lack of imagination to see what can happen when you are dealing with a larger environment...
I like MS products a lot. Exchange I don't like quite so much. But my job right now is to work with it in large enterprises. I am an AD guy, love working on it and doing things with it. However, someone figured out I was really good at figuring issues out so they moved me to go work on Exchange, what does that say about Exchange? I think Exchange could be a great product, if I didn't, I wouldn't bother telling MS what I find wrong with it and I tell MS a lot of things I find wrong with it. My main wish for Exchange is to stop monkeying around with new stuff, get the core solid and stable and running well. The core being AD/Exchange integration, I still see Exchange as a perfect example of how not to write a AD enabled application as well as a great example on how not to implement security when using AD. Get that core straightened out, then lets start moving on to other things. In the meanwhile, lets also get management at scale handled as well. If we correct that AD/Exchange interface, that problem could almost solve itself since there is tools for management at scale for AD and/or lots of people with the current knowledge on how to do it through LDAP.
joe
It seems silly for customers to have to write an interface to manage Exchange when you are in the process now of making changes to the management interfaces. It sounds like a good time to ask for and hopefully get, more flexibility in what you provide. At some point, you guys (Exchange Dev) need to realize that not everyone runs everything from Windows like many of the other groups are realizing. Look at the R2 offerings, how much of that is directly related to helping people interoperate amongst multiple platforms? You guys seem to be out of step with the rest of MS Dev. Also, it would suck for a customer to create an entire management interface only to have MS decide, well what we did in E12 was wrong, we are going to change it again. Most companies out there using your products are not software development houses.
While on the topic of modifying AD directly, if you guys intend to continue using AD for the backend store of info, Exchange needs to be smarter about checking validity of info before using it. As mentioned, it is possible to directly modify things so that means that AD is an untrusted source of data. The data needs to be validated before being used. Duplicate values, etc in AD shouldn't bunch Exchange up, it should run into it, validate it, and indicate that isn't good and then ignore it until it has been corrected. Again, it is a data source that resides outside the body of Exchange so, according to all secure programming practices, be considered untrusted and needs to be treated as such.
Also, Exchange/Outlook needs to either look at its own store or look at AD. This situation of looking in both places and doing things is a support quagmire. Permission and security is a great example, the mailbox ACL either needs to be in the store or it needs to be in AD, pick one. As well as how publicDelegates are handled. I previously ran into a great issue where Outlook would update the publicDelegates and the store piece would be cleared out but the AD Piece wouldn't and Outlook would show you that it was all fine, right up until someone could still send mail on behalf of someone else and no one could figure it out until they looked at AD directly instead of with Outlook. There are probably many folks out there right now with multi-domain Exchange deployments who look at outlook and see publicdelegates and think that is right when in fact, AD has additional folks as publicDelegates on those accounts.
Also, back to
"#5: Actually the monad way to do it is to get all the data back and select only what you need. For example: $stats = get-mailboxstatistics "domainuser"; $stats.LastLogonTime. Or you can do get-mailboxstatistics | select-object LastLogonTime. Either method will work."
Doesn't that seem a bit heavy if say you are looking to get the size of mailboxes for all users across an org of 200,000 mailboxes or even 2000 or list which users have mailboxes over x MB? You have to pull all info for all users and then throw it all away except for one small piece of info for all users.
It is a scaling issue. This stuff works fine in a lab with 2 exchange servers running with 50 mailboxes with unlimited network/cpu like I have in a home lab, but when you get to the real world the lack of imagination from MS in running large orgs comes to the forefront.
This is evident when you look at the current tools and how they only allow you to work within a single Org or the WMI providers that don't accept a domain and a userid or even the DNs being used since they point at people used to doing everything from the GUI which is generally not very efficient.
I am afraid we are turning in some silly limitations for others. If you have to return all info for a mailbox to get one or two pieces is how you intend to do it, you might as well tell people now in good docs how to build their own management interfaces that run on the exchange servers so they can write their own efficient mechanisms for doing things.
Again, what you have now even works fine in small companies, but MS is pushing to take over large companies and have huge email systems out there, I, being someone who works with companies on this stuff, would love to see it so I don't have to sweat blood to make it work well, the way that MS shows the CEOs and CIOs in brief look how cool we are displays.
Right now I am trying to figure out how to efficiently get a listing of all rules across all mailboxes in a 200k user org because of what appears to be a poor implementation of the rule "from a DL" which seems to have serious impact on Exchange servers because of the additional LDAP expansion queries that has to occur. You might think something like that wouldn't be too difficult. You would be wrong. If I had only 50 mailboxes, I could easily just go look myself, that stops working somewhere around several hundreds of mailboxes. Heck, the "from a DL" rule wouldn't even be an issue in a 50 mailbox org, the server could easily handle that additional expansion work again.... Again... scale issues and lack of imagination to see what can happen when you are dealing with a larger environment...
I like MS products a lot. Exchange I don't like quite so much. But my job right now is to work with it in large enterprises. I am an AD guy, love working on it and doing things with it. However, someone figured out I was really good at figuring issues out so they moved me to go work on Exchange, what does that say about Exchange? I think Exchange could be a great product, if I didn't, I wouldn't bother telling MS what I find wrong with it and I tell MS a lot of things I find wrong with it. My main wish for Exchange is to stop monkeying around with new stuff, get the core solid and stable and running well. The core being AD/Exchange integration, I still see Exchange as a perfect example of how not to write a AD enabled application as well as a great example on how not to implement security when using AD. Get that core straightened out, then lets start moving on to other things. In the meanwhile, lets also get management at scale handled as well. If we correct that AD/Exchange interface, that problem could almost solve itself since there is tools for management at scale for AD and/or lots of people with the current knowledge on how to do it through LDAP.
joe