Thursday, September 06, 2007

IdM vendors not supporting Exchange 2007?!

There are some storm clouds on the horizon that I don't think most people have seen yet and it will be interesting to see how the identity management vendors weather it...

Most identity management implementations include provisioning/de-provisioning of mailboxes and updating mailbox related information like distribution lists. In today's world, most mailboxes are probably Microsoft Exchange-based. If that's you, read on. If not, the bad weather is going to miss you entirely.

In Exchange 2000 and Exchange 2003 vendors relied on the "Recipient Update Service" - RUS - to interact with Active Directory. This made it easy to create, read, update and delete identity information for Exchange via Active Directory and LDAP.

In Exchange 2007, RUS is no more. RUS has been replaced by Exchange Management Shell cmdlets. The key word in that last sentence is "cmdlets". What the heck is a cmdlet?

A cmdlet is a command implemented by deriving a class from one of two specialized Windows PowerShell base classes --Microsoft.

What Microsoft has done in Exchange 2007 is move certain functionality to the Exchange Management Shell. Some of the functionality that has been moved to the Exchange Management Shell includes:

  • Mailbox creation (create mailbox, mail enable an Active Directory user)

  • Mailbox management (enable/disable mailbox, set mailbox attribute)

  • Distribution group management (set, enable, disable, add/delete members
And "moved" means that it is no longer possible in an Exchange 2007 environment to use Active Directory and LDAP to expose this functionality. What does that mean?

If your identity management provider does not update their product(s) to use PowerShell then they will cease to be able to create, delete or modify Exchange users or distribution lists. How serious of an issue will this be for you?

I've been trolling around looking to see which identity vendors have specifically announced support for Exchange 2007 I can't find anyone. Through Quest's ActiveRoles product we support all of these capabilites because we've built in support for PowerShell. When I checked some of the IDM vendors sites here's what I found:

  • IBM Tivoli Identity Manager 4.6: "Use the Active Directory connector" - When I checked their documentation they mention how the AD connector is used to set various Exchange attributes and for provisioning/deprovisioning mailboxes but there is no specific mention of Exchange 2007 support. My guess: IBM's TIM does not support Exchange 2007. My August posting to the Tivoli User Forum resulted in no responses - go figure.

  • Sun Java System Identity Manager 7.0: "Microsoft Exchange 2000 and 2003 are managed through the Microsoft Windows Active Directory 2000 and 2003 resources" - My guess: Sun's product does not support Exchange 2007. In fact, if you check out this post on their developer forum you'll see how one customer had to debug PowerShell scripts themselves.

  • Microsoft's Identity Lifecycle Manager 2007 (aka MIIS): This is the one solution that you'd expect to support provisioning Exchange 2007 mailboxes but it doesn't! The ILM 2007 FAQ does not list support for Exchange 2007.

Now this isn't the end of the world yet - as I said, the storm clouds are on the horizon - because this issue will only be manifested in a pure Exchange 2007 environment. Most of us are probably going to run a mixed environment for a period of time. However, better to be forewarned than have your hair on fire, your auditor's hair on fire and your boss' hair on fire, because provisioning/de-provisioning no longer works!

Start asking your IdM vendor about their plans to support Exchange 2007 now.




7 comments:

Andres Rodriguez Canello said...

ON ILM Product Overview page it says that Exchange 2007 is supported, take a look...

http://www.microsoft.com/windowsserver/ilm2007/overview.mspx

Andres Rodriguez Canello

Unknown said...

Andres - I believe that is what I call a "half-truth". Yes, Exchange 2007 is supported if you have Exchange 2000 or Exchange 2003 also deployed - a mixed environment.

In a pure Exchange 2007 *only* environment MIIS/ILM does not work out of the box and requires specific PowerShell coding to enable Exchange 2007 mailboxes once they are provisioned.

If I could get on to the TechNet MIIS forum I'd send you some links to customer comments about this issue but I haven't been able to get on for the last week for some reason.

Brent Kynaston said...

Our company TriVir LLC has written an identity management connector for Novell Identity Manager that integrates natively with Exchange 2007 through the PowerShell interface. For more information email info@trivir.com.

Regards,

Brent

Anonymous said...

Novell Identity Manager 3.5 has support for Exchange 2000/2003 and also for Exchange 2007 - So I advise to look at this IDM solution as it covers more bases than any of the others - and by the way has been in the market at lot longer = more mature :-)

Unknown said...

Bjorn - I have no doubt that Novell's solution supports Exchange 2007 - in a mixed Exchange environment (i.e., Exchange 2007 servers running with Exchange 2003 servers)

My point - and I am happy to be corrected - is that IDM vendors do not *yet* support provisioning to a pure Exchange 2007 environment!! In other words, the only Exchange servers running are 2007.

If you get information that Novell supports this please point me to where you found it. I've been looking for it!

Thanks for reading,

Jackson

preethy said...

Hi,

I would also like to add...

Tivoli Identity Manager 5.0 has an official support of Exchange 2007 using it s 64 bit AD Adapter.

_Preethy

Unknown said...

Jackson,

Our EmpowerID Identity Management platform fully supports Exchange 2007 management using PowerShell. Our Windows workflow-based platform provides all of the major Exchange PowerShell commands wrapped as workflow shapes that you can drag and drop into any process. PowerShell commands are wrapped as WCF web services so you can execute them through firewalls and they have built-in authorization so if a user cannot execute the operation they are attempting it will automatically get routed for approval to someone who can. We even have a wizard that allows you to browse any PowerShell command from any library and add it as a web service, workflow shape, and RBAC-protected operation. We'd love to wrap your Quest PowerShell library so customers could use them in workflows with web interfaces and built-in authorization. Maybe something to discuss ;-)


Patrick Parker
The Dot Net Factory
www.thedotnetfactory.com