As discussed in the earlier blog post introducing the new Exchange 2007 console, the Exchange Management Console GUI has been completely redesigned in Exchange 2007. While redesigning the Exchange ...
Updated Jul 01, 2019
Version 2.0
Blog Post
Sounds much more like a development resourcing issue than an actual attempt to provide a beneficial feature as is implied by this blog post and previous ones.
Let's be serious here. The Exchange attributes are still stored in Active Directory. So ADUC could still be handled, with or without powershell. I don't see how supporting one obviates the other - that's broken logic if I ever saw it. The biggest difference is possibly increased support load- but for something as commonly used as this, if that's what it takes to make customers happy, it's usually worth it.
Evan, I have a lot of respect for you and the team, but when you make a comment like "We decided that we could cover a LOT more of the customer requirements for a LOT more of the customers if we instrumented recipient management with powershell to match the rest of the management infrastructure and integrated recipient management into the shell and console directly" - that's where you lose me.
I can agree with everything in your statement, with qualification. You dropped out the part where you break important and commonly-utilised functionality in the process, and try to justify it with half-baked excuses that only serve to illustrate how short-sighted and ill-advised this type of decision is.
Let's be serious here. The Exchange attributes are still stored in Active Directory. So ADUC could still be handled, with or without powershell. I don't see how supporting one obviates the other - that's broken logic if I ever saw it. The biggest difference is possibly increased support load- but for something as commonly used as this, if that's what it takes to make customers happy, it's usually worth it.
Evan, I have a lot of respect for you and the team, but when you make a comment like "We decided that we could cover a LOT more of the customer requirements for a LOT more of the customers if we instrumented recipient management with powershell to match the rest of the management infrastructure and integrated recipient management into the shell and console directly" - that's where you lose me.
I can agree with everything in your statement, with qualification. You dropped out the part where you break important and commonly-utilised functionality in the process, and try to justify it with half-baked excuses that only serve to illustrate how short-sighted and ill-advised this type of decision is.