Multi-Release Strategies and Role Based Access Control

Following the ‘why we built Exchange the way we did’ theme, I wanted to take some time to explain some architectural changes that have been made to Exchange over successive releases.

After Exchange 2003 shipped we took a step back and assessed the state of the code base. At that point, Exchange had grown fairly organically over the various releases since the start of coding about a decade earlier. It was clear that there were assumptions built into the core architecture that were no longer optimal given the steady but exponential changes that were accumulating in the hardware we ran on and in the way customers were using the product. One option was to start with a blank sheet and attempt to rewrite the product in one release. 

We decided this was not a likely path to success given the large scope that Exchange had evolved to encompass. However, it was also clear that dramatic changes were needed and that we had exhausted our ability to approach Exchange development in a feature-by-feature and release-by-release manner.

The 3-release refresh cycle that we embarked on is a subject of a future video posting. So rather than talk about the broad approach, I thought it would be better to start with an example of an important scenario that we delivered as part of Exchange 2010 that had its roots in some key Exchange 2007 investments.

Specifically, this video focuses on the RBAC story in Exchange 2010. In it I explain how the role based management delegation story in Exchange 2010 is rooted in, and was a key driver for, the work to switch to a verb oriented, task/cmdlet-based system management infrastructure back when we were planning the 2007 release.

This is a great example of a multi-release strategy successfully solving a problem that had eluded previous attempts to build useful management roles in the scope of a single release.

Perry

Comments

• Anonymous
  February 16, 2011
  Thanks. This will help me with explaining the new model as we deploy Exchange 2010. Noun/object vs verb is a good overview. I think we have something like 2000 IT people who need access to various Exchange admin tasks (yes they do other things!) and RBAC is going to help keep them tied down on certain things while allowing us to actually give more power to them (things we had to hold back in the past because it would have let them break a whole bunch of other stuff.) It's funny though because it's looking like some of the roles will be so restricted (limited input and basically one possible outcome) that we could just replace the IT guy with a script, put a nice front-end on it and give access to the end-users to self-provision. Basically the ECP. Looking forward to seeing more self-service options in the coming releases.