Super Agent 2.0
by Deborah Volk on August 5th, 2009

It has been years, literally, since I have heard anyone talk about agent vs agentless. Both sides have spoken, and I believe the resolution has been passed: Agentless (by that I mean nothing installed remotely from the server) whereever possible, then use agents. And in today's climate of open standards and secure communications, it seemed like "whereever possible" was everywhere. Thus, the debate died and it became an afterthought.
Then comes Microsoft Exchange 2008.From a remote java perspective, Microsoft Exchange was all figured out.Java applications utilized JNDI to communicate with the MS Active Directory Domain Server to set initial MS Exchange attributes, then the MS Exchange's RUS (Recipient Update Service) finishes the object.There are certainly some inherent problems in this approach (for example, latency from the service perspective), but it allowed a remote (from the AD/Exchange domain controller) application to provision MS Exchange.And that remote application did not even have to be running on a windows machine -- a truly agentless topology.

With the issues facing the Exchange RUS, Microsoft decided to remove part of this service in MS Exchange (for a good blog entry on this, read here) and make the user fully provisioned once they are created in the console GUI or by command line.Making the logical leap, we can then assume that the way to get users fully provisioned is through the console GUI (ADSI) or by command line (which in fact is true, as the cmdlets are the "API" to Exchange now). This is fantastic, your application is residing on a machine with the Exchange Management Shell(command line) or it has monkeys working in the background fat-fingering in data in the GUI.But if your application isn't in either one of these situations, then you are back to one less agentless connector in your pod.

For the IDM tools that are used to playing with older applications that didn't make it into the alphabet soup of communication standards, this isn't much of a problem as far as implementation of a solution is concerned.But for IT operations everywhere, the age-old, dead-horse beaten agent/agentless argument will start rearing its ugly head again.

Posted in not categorized    Tagged with no tags


K. Brian Kelley - August 6th, 2009 at 8:28 AM
Not ADSI, but PowerShell, even through the GUI. Microsoft moved Exchange 2007 to be fully scriptable using Cmdlets and is supposed to be implementing that through all of their core server products, where the GUI calls the proper PowerShell scripts. Though admittedly this didn't happen with SQL Server 2008. There are Cmdlets, but the GUI doesn't call them, so far as I am aware.

The Cmdlets are based on the .NET Framework, so it may be possible to interface with them from a non-Windows box using Mono, but it's not something I've really seen any literature with people trying.

Deborah - August 6th, 2009 at 11:04 AM

You are right.. powershell.

Web services are definitely an alternative, but it is still something you (the IDM application owner) would have to have installed on the Windows box (and here we can get into the semantics of what an agent really is). At least the nice thing about an "agent" like that is that if done right, other applications can use it too.
Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)