May 2004 - Posts
So, I'm doing some research into Windows SharePoint Services (WSS) and ran across this website:
http://www.sharepointcustomization.com
I'm not sure how long this has been available, but I thought it was pretty handy.
- Conrad
You know whenever I think about Identity Management, I always think of a big political and technology mess. I'm sure many others do too. For if there wasn't an Identity Management mess, we wouldn't have products and technologies like Identity Integration Server (Microsoft), Java System Identity Manager (Sun), WS-Federation, SiteMinder (Netegrity), COREid (Oblix), and many more.
Why has it come to this? Well I think it comes from the general chaos of software development. Every time we write a new piece of software, we always seem to introduce a new primary key (please excuse my SQL lingo) to identify a unique identity. From there, the beginning of our ID management nightmare begins. The nightmare only get more intense when we need to link/sync/etc. identities from one system with another. This is why products and technologies listed above are created to help sort the whole thing out, but make no mistake that using an off the shelf product or technology is only part of the answer. This is because, by the time an organization thought it was important enough to invest in an identity management solution, the mess has already gotten out of control.
The mess that I refer to isn't just the numerous systems that contain identities (not all of them unique either) or even the varies platforms, protocols, and API's needed to access that information. I'm referring to the number of organizations and politics that "own" pieces of the data. Day to day business decisions, boundaries, and politics seems to be the biggest barrier to getting an identity management solution executed. And it's not just because some people can't let go of their control of the data (but it IS a big part of it), but it's also because there isn't anyone (or team) with the organization that know where all the data is or who owns the data (and why they own it).
Now, even once you fight through all of the political and business issues, there still is the large task of choosing the right technology strategy to implement. Each technology has it's pro's and con's, but they have something in common: System Integrators. This is due to the fact that you can't just drop an Identity Management product in on day one and link all of your back-end systems, and perhaps external data (e.g. outsourced payroll systems), with little to know integration. Sure, an organization may have some talented developers and engineers, but do you really want to focus them on fixing your Identity Management problem when they could be developing new solutions to drive business? Ya, I didn't think so. So this is where an SI with the expertise to connect your system together. But even this is just another small baby step.
In order to best leverage your investment, all new third party products that are purchased should integrate into your environment by the time the service is put into production. This will remove, or at least greatly decrease, the integration/migration woes when connecting with your now existing Identity Management (IdM) solution. But this is not likely to happen. Why? By the time the IdM solution is in place, it has become an important part of the core back end system processing. Which also means that we have now centralized the IdM solution. To be as kind as possible, we've just made a new king or committee that "Safe-Guards" the system. Hence, we've just created a new bureaucracy.
So now, a local IT person deploys a new software package (off the shelf product, custom software, etc.), it becomes popular, and when it reaches to the point where it now needs to integrate with the IdM solution, it's now time to place another call to your System Integrator. Even when an organization has an IdM solution, there will always be applications that are created and deployed without the IdM in mind.
There are a few things that could have made this scenario a bit easier.
- What if the product shipped with a "plug-in" to a given IdM Product? That sounds great if there was only one IdM product on the planet (I know my friend at Microsoft are hard at work on this one :) ). But with so many vendors, I think Software Product companies are staying away from investing in this right now.
- Perhaps another Industry Standard? Perhaps this could be a solution, but
- Keep your favorite Systems Integrator (eQuest) on speed dial. This is today's Status Quo, but without the above options really being implemented throughout the industry TODAY, this is really the only option available.
So, if you're starting to see that your organization might have an Identity Management issue, you probably already have one. (Another shameless plug coming) When you call your System Integration , like eQuest Technologies (there it was), you should keep in mind that you'll need to have many of your business issues worked out prior to picking the right technology. This can either be done before or with your SI.
Conrad's stream of conscious is now over (lucky you!). More later...
Conrad Agramont, Senior Architect, eQuest Technologies, conrada@eqinc.com
Paul Edlund from eQuest Technologies provides us with his “quick” view on the command-line tools that come with Microsoft's Automated Deployment Service (ADS) available with Windows Server 2003. The post is available on a new community I created to focus on all things Automation (Back Office) and Provisioning with Microsoft Technologies. The community is called, (drum roll for the lack of creativity...) “Provisioning Community“. - Enjoy!
http://groups.msn.com/Provisioning/ads.msnw?action=get_message&mview=0&ID_Message=7&LastModified=4675472181288694282
- Conrad
I just finished doing a post on the MPS Community site about MPS working in a Multi Domain/Multi Forest deployment and thought I might do a quick blog entry about an MPS related topic. Hey it's in my head and I'm on a role....
OK, so perhaps these aren't really dirty little secrets. But they are dirty and they are little, so I thought I'd shed a little light on them.
1. MPS really isn't that smart
So often when I talk to customers about MPS, they always ask the following type of questions
- "Can MPS scale to 1 million or more users"
- "How do I update MPS with my current user base"
- "How does MPS keep track of the services customers have"
- etc.
The simple truth is that MPS really doesn't know much about what it's doing. At the core of MPS is the Microsoft Provisioning Framework (MPF) or as we sometimes call it , "the Provisioning Engine." The role of the Provisioning Engine isn't to keep track of which user or organization has a given service or map a customer to all the services that they consume. All the Provisioning Engine is responsible for is ensuring that all of the tasks performed are done reliability and the details audited. That's it! When MPF performs a set of tasks, it does so based on the set of instructions defined within a procedure (procedures are defined in XML and use XSLT for data transformation). MPF has NO idea what those tasks are actually doing and it doesn't care. It's the responsiblity of the calling application (or just something out there) to keep track of customer service data. Now could you integrate that into MPS via a provider that communicates to your customer care application? Sure, but it's not there out of the box.
2. IIS and Exchange Resource Managers aren't "fix", or are they?
When MPS 1.0 shipped a few years ago, it shipped with two resource managers: IIS Resource Manager & Exchange Resource Manager. Each resource manager is defined as a namespaces and stored in MPF just like any other namespace. Both of these Resource Managers are actually a Resource Manager Instance (RMI - I just invented the term/acronym...it's all my time in the US Marine Corps and then Microsoft that makes me an acronym junkie...oh, back to my point). The reason I say they are an instance is because they both use the MPF Resource Manager (BlockModelRMO & CoreRMO). The MPF Resource Manager Provider uses a single database to store all of the data for each resource manager.
Now just like all of the other namespaces and procedures in MPF, everything is defined in XML. So the definition of the Exchange and IIS Resource Managers are all there in "plain English." So one would think that changing how the Resource Manager works and behaves could be done easily. In theory (well I guess in practice too), anybody can do this (keep in mind the support issues), but practically it's just way too hard to do. This is because the XML language that is used to update and query the Resource Manager is very complex and difficult to understand. It's one thing to spend some time to learn how to create your own RMI, but it's another to modify an existing one.
So what does this all mean? Well it means that you could change the way an RMI works, but it would be so difficult that you wouldn't do it on your own. You would have to get a System Integrator (oh wait...here comes the pitch) like eQuest to do that type of customization for you. Or you could wait until the next version of the Windows Based Hosting or Hosted Exchange Solution to ship an update.
There is another option. This is something that I've been thinking about for quite some time...
One of the great things about MPF is that all of the namespaces and providers are defines as XML. So if you make an update or a complete rewrite of a given namespace or provider, there is no version conflict that will take place for all of the other namespaces the use the modified namespace (this only works if the data in and out remain the same). This provides great flexibility to make modifications on how the logic within a given procedure works.
So the idea is to create an actual Exchange Resource Manager Provider that implements the same interface (and more) as the current Exchange Provider. The namespace name and methods would be named the same as the original RMI, but now map to a .NET Component that performs the functions and stores the data against a normalized SQL Database and tables designed exclusively for Exchange Resource Management. This makes the development and customization of the behavior of the Resource Manager as simple as modifying some C# (or perhaps VB.NET for some) code and maybe a SQL table change. That's much nicer than dealing with the constraints of the MPF Resource Manager.
Interested? Drop me an email: conrada@eqinc.com
3. Hosted Exchange namespace does it all! (But what if I only want a piece)?
Have you ever gotten something from Microsoft that's only part done and when you ask how to enable the "end to end" scenario they tell you that you're on your own? Ok, well this is like the reverse of that. The Hosted Exchange 2003 solution provides an "out of the box" (doesn't ship in a box...but you get the point) solution that enables you to quickly enable the "end to end" scenario for provisioning Hosted Exchange.
Now from a get up an running quickly, training, or I just need something that works now type situation, this is a great thing! But it does cause some issue when there are only pieces of the solution that you want to deploy. Let's take for example a Service Provider that has already deployed a Hosted Exchange 2003 offering and wants to use the latest updates from the the Hosted Exchange 2003 solution to go over the 1000 GAL and OAB limitation. The ability to do this with the Hosted Exchange 2003 solution in this scenario is quite feasible, but not straight forward or easy. This is because all of that logic and "know how" is nestled way in the Hosted Exchange namespace.
So does this sound like something that you're currently looking into? If so, (oh no...not the pitch again) feel free to drop me an email.
Well that's all of now. See nothing really secret about it, but not obvious either.
Conrad Agramont
Senior Architect
eQuest Technologies
conrada@eqinc.com
More Posts