Just sat through today's PDC05 keynote which included an hour on the blessings of the new office system 12, which seems like the SAP for the information worker.

Complexity in terms of what it will do and how it will integrate is going absolutely through the roof. You can now do things so complex, integrated, elaborate, good looking etc. that you find yourself longing for the days of text email, phone calls, and binders.

The careful business executive should definitely think twice before moving up to all this new technology. If you think that your people didn't use but 10 % of the features of Office you will probably be going down to 5 % with this upgrade.

... but then again, if access, accuracy, and availability of information is part of your competitive edge - like really, not just your feel good edge - this upgrade may be for you.

Authorization Manager, or just AzMan , is authorization feature available with Windows 2003 and backported to Windows XP and Windows 2000 of appropriate service pack levels.

For details, please refer to other articles such as the MSDN Magazine November 2003 article Authorize It: Use Role-Based Security in Your Middle Tier .NET Apps with Authorization Manager which explains well what AzMan does and how to use it.

Still I would like to point to a few areas of AzMan worth noting before deciding to use it in a production setup. AzMan is basically a rather simple feature based on a great concept. Still, as implemented in the current versions of Windows its adoption is probably held back by a few missing details.

AzMan in its current incarnation will ride on top of an authorization store hosted in either a simple XML file (with no associated schema), in Active Directory or in Active Directory Application Mode, ADAM. Using a file based store is not advised except for your development setup – in which case it is great. Using Active Directory gets you the performance and robustness you need, but requires that you raise the domain level to Windows 2003 functional level. Using ADAM is a fine choice, and presents only a few challenges in more advanced combinations with AzMan.

The biggest challenge with AzMan is defining your application in terms of Operations, Tasks, and Roles in a way that lets you move that definition forward through the stages of development and deployment. Following a common path you start out with a file based XML store, where you configure and test the setup. But as soon as you want to move the contents of the XML file forward into another environment with an AzMan store based instead on e.g. Active Directory, the missing export/import facility is brought to your attention. As it turns out you are left with only two options: either you manually configure the AzMan application definition for each deployment stage in each and every cycle, or you write you own service (preferably an MSI Installer custom action) capable of treating an AzMan XML store to a new home inside Active Directory.