Tools for Moving to a Microsoft Collaboration Platform

Blogs about the tools and solutions used in moving to a Microsoft collaboration platform.

The long-hard days in the fall

The long-hard days in the fall

  • Comments 7
  • Likes

The fall of ‘05 was an interesting time for our team.  We had been pulling long hours for several months working on several projects  (getting ready for the initial release of the messaging tools, revamp of the Application Analyzer, and starting work on the Application Transporter.)  Those were long-long-hard days, but it was great seeing the vision become reality in all the different releases we have had in ‘06.   In addition, it was great to see all the interest  from the community about our work.

 

So here we are in the fall of ’06, again putting in long, hard days on the next wave of coexistence and transition tools.  Last week we hit a major internal milestone with the initial beta release of these tools and again I am amazed how far we have come from the initial visions to the products that will be coming out.  This next wave is really going to take it to the next level.  Not only does it focus on coexistence and migration to the latest Microsoft technologies, but administrators will now have/see more flexibility, reliability and programmability along with improved overall ease of use.  Plus, we are introducing a new technology model that will enable us to quickly improve and add new scenarios over time.

 

Anyway, it is a great time right now seeing it all come together. This Friday, we will be showing the beta bits publicly for the first time at IT-Forum in Barcelona.  Given the interest we have seen for the current tools, it going to be fun showing the next wave !

 

Want to know more?  Just ask…  I will blog updates from IT-Forum.

 

Erik
(Yes blogging again!)

Comments
  • Anything that improves the reliability and basic functionality has to be a step in the right direction.  Current version leaves plenty of room for improvement.

  • Most of the reliability issues are around the mail connector for a couple of reasons.  First we are reliant on the Notes API to access/convert mail which we have seen several hangs/crashes in.  We have protected these when they come up and IBM has fixed many (Why we recommend the latest Notes client installed on the connector.)  However there may be more, and if any are seen customers should report as soon as possible.  Second (more important) is the single point of failure that the connector represents.  You can have multiple connectors but due to IBMs design around foreign gateways, you can only have one route to a foreign system per domain.  In addition you cannot cluster a foreign gateway.  This results in a single path for mail flow between a Domino domain and Exchange.  Should that path have a problem (in software or anywhere else) then mail stops.

    With Exchange 2007, we have changed to use SMTP at the mail transport, leveraging the native support of MIME and iCAL in both Exchange and Domino.  This increases reliability because there is now no extra code that sits between Exchange and Domino and we no longer rely on the Notes client API to convert mail.  In addition both Exchange and Domino support redundant SMTP routing so fault-tolerance and load balancing can be configured.

    Erik

  • We have a ticket open with support, but they are keen to just point the finger at IBM.  It's your connector, you need to support it!

    I am pleased that you are using SMTP moving forward.  This seems the obvious choice (I always wondered why that was not how it was designed already!)

    How will free time sync be addressed with the new release?

    When will the new version be available?  Does if have to run on Exchange 2007 server?  If so, can I just upgrade the existing connector server and leave everything else at the 2003 version?  Hopefully backward compatibility was a part of the design!

  • The support for the connector lies with us, as it always have.  Even if there is an IBM problem issue we will change the connector as needed to either work around the problem or find another solution.  In the case where the API hangs/crashes we will build in a protection or see if there is a workaround in the connector to avoid the problem in the first place.  Either way we own the change in the connector.

    We could not use SMTP earlier due to the installed R5 base.  R5 did not support iCAL and MIME, and as a result all calendaring and rich formatting was lost.  We made the call to no-longer support R5 directly to E2k7 since we are now seeing a majority of domino users on R6+.  R5 customers can still co-exist but they will require using the current connector on an E2k3 server.

    We should have the new versions available this winter (we are not announcing a date right now) but we are planning on being near to the release of E2k7.  Given that mail/calendaring are just native SMTP (no real code), you will need an E2k7 server.   In addition, we will absolutely support upgrade from an existing E2k3 topology with E2k3 connectors.  You will need an E2k7 server since E2k7 does not have in-place upgrade, but we will convert the existing directory entries and will work in mixed E2k3/E2k7 topologies.

    Finally, Free/Busy will remain a separate connector, similar to what is available today.  There are some changes given how E2k7 handles free/busy but the same general mechanism is used.

    Erik

  • Thanks for the updates Erik.

    To summarise, I could install a new e2k7 server to act as the email and free/busy connector.  This would convert all the existing entries and allow all our other e2k3 to exchange email & invites with full fidelity and keep free time searches current between Exchange and Domino.  All our Outlook 2003 Cached mode clients would work with full features?

    I would then remove the existing e2k3 connector server.  

    Lastly, why don't MS support in place upgrades?  Requiring new h/w just to upgrade seems a bad idea conceptually.

  • That's the idea.

    The Exchange upgrade decision (as far as I recall) was based on the 64bit requirement.  There was several blogs about this on the Exchange team blog http://msexchangeteam.com/archive/2005/12/29/416613.aspx

    Erik

  • Any links for how to configure dirsynch?

    We still need to create Notes IDs as well as AD accounts.  Manually creating IDs on both sides causes email not flow from Notes to Exchange, without manually adding the hierarchical Notes address to the AD user object.

    Would love to be able to get the automated somehow.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment