There isn’t transport stack in the Microsoft Transporter Suite for Lotus Domino. We have switched the transport stack from using the Exchange Development Kit Gateway from the Connector for Lotus Notes which was available in Exchange 5.5, Exchange 2000 and Exchange 2003 to using SMTP  between Domino and Exchange. Yes, you read it right, SMTP, this means no more MFCMAPI/GWCLIENT to check out the MTS-IN and MTS-OUT on the Connector Server or exchange.box/exchange.bad on the Domino server.

The key reasons were to increase performance and reliability between the two messaging systems using a standard industry protocol. It also takes advantage of the iCAL format when sending and receiving meeting request information between the two messaging systems.

Currently we have tested and supported two methodologies for deploying this strategy in your environment. The first methodology is using sub domains within a single domain, for instance Contoso.com would route between the two systems by using exchange.contoso.com for Exchange and domino.contoso.com for Domino. The second methodology is if the domains were different, such as an acquisition scenario,  contoso.com buys litware.com and they only need to synchronize information and send/receive e-mail. With both of the previous scenarios you use the same options in Exchange and Domino. In Exchange you will be using the configuration options for Send and Receive Connectors, Remote Domains, and E-mail Address policy. In Domino you will be using the configuration option for Foreign SMTP Domain Document and Connection Documents. This is all SMTP routing based, the majority of this is documented in our help file within the Transporter Suite documentation. Based on feedback from the beta, we will be working to write some more specific scenarios in an upcoming document. More information can be found about SMTP routing from the two web sources listed here:

Microsoft Exchange 2007- http://technet.microsoft.com/en-us/library/bb124558.aspx

Lotus Domino -IBM

Hi again!  We talked briefly before about what was new with directory migration, but you may well ask what have you done for me lately?  Well I’ll tell you.  Directory migration wasn’t the only place we made improvements, mail migration also got some love.  

1.  Performance!  We’ve improved performance for mail migration in a couple of ways.  First of all, whereas we used to write everything to disk and then read everything from disk between extraction and injection.  Now everything is passed from the extractor to the injector in memory, so you no longer have to take the disk I/O hit in migration.  Secondly, we’ve implemented multi-threaded mailbox migration, which makes us much faster than before.
2. Merge Mode!  Let’s say you’re migrating a 2GB mailbox, and somewhere in the middle, you lose network connectivity.  In the past, if you re-migrated the whole mailbox, you’d get duplicates of any messages that had already come over.  You could limit the re-migration down to a specific date range to overcome this, but that solution is a little cumbersome.  In the new world order, we have merge mode!  Now when you re-migrate the mailbox, we’ll detect which messages are already there and not re-inject them.
3.  No More SC2!  We now have better calendar content fidelity in migration, which is possible because we now inject calendar content directly into the target mailbox instead of sending it through an SC2 file along the way.
4.  Web Services!  Our mail injector now populates the target mailbox through Exchange 2007 Web Services.  We used to inject using MAPI, which meant that the ports that you needed to have open between the migration client and the target server were all of the MAPI RPC ports.  Web Services uses HTTPS, which means that 443 is what you need to have open between you and Exchange for mail injection.
5. PowerShell!  Like the rest of our tools, all of this glorious functionality is exposed through PowerShell tasks, which infuses you with Fabulous Scripting Powers (fabulous scripts to follow)!

--Jenna

With this blog I would like to open a series  of Connector blogs and will start with what is new in Transporter Connectors.

We have made significant changes in this release of Connectors in Transporter Suite, including:

1.       Ability to configure and control Connectors through Power Shell independently. Connector Tasks are divided in to two sets: DominoDirectoryConnector and DominoFreeBusyConnector and each supports 6 tasks: New, Get, Set, Remove, Start and Stop. The “New” commands create the appropriate connector object in the Configuration Container, and the “Set” tasks allow you to fully configure those objects.  The “Start” and “Stop” commands allow you to start and stop the service, one service per connector unlike previous version. Using Start command with a combination of self-explanatory keys (–FullReloadToAD –FullReloadToDomino –UpdateToAD and –UpdateToDomino),   you are able to control synchronization.  And obviously the Remove task allows you to delete Connector object from AD.

2.       Directory Synchronization can be deployed as a standalone connector and does not depend on mailflow, however FreeBusy connector requires objects to be populated by Directory Connector on both Domino and AD. The Directory Connector design supports standard as well  shared name space configuration.

3.       Directory Synchronization can be set up through a wizard that allows you to choose one of 4 sync modes with a simple explanation of each action.

4.        Although the Directory Connector is not designed to perform direct upgrades from previous versions, through Power Shell with DominoDirectoryConnector you can take ownership of the DirSync objects created by E2K3 Directory Connector.

5.       The Connector configuration previously set in the ini file has been converted to XML format and dramatically simplified.

6.       Mapping tables are much simpler and file names are easy to follow.

Separating the Directory connector from messaging allows us to use the industry standard SMTP protocol for mail transport, which brings reliability, better SMTP/MIME format handling, ability to leverage existing servers and SMTP paths, and predictable performance.

New GUI allows the admin to configure and control both Directory and FreeBusy connectors from the same screen as well as perform migration of Domino users, mailboxes and applications.

And at the end I would like to mention that Power Shell allows you to set the Connectors’ diagnostic level through Get/Set-TransporterEvenLogLevel, and that is a perfect tool for troubleshooting connectors. Thank you and let me know if you would like to see blog for specific area.

Have a great day.

Kahren

After the release of the public beta last week, I thought it would be fun/good to have an open Live meeting to allow everyone to meet the team, do some demos, and answer some questions.  So consider this your invitation to join us in a review of this recent release.

Erik

Tuesday Jan 30th, 2007  10:00am PST

Live Meeting: Meet the Microsoft Transporter for Lotus Domino 2007

LiveMeeting Attendee URL:

https://www.livemeeting.com/cc/microsoft/join?id=99F23F&role=attend&pw=TS2007

Internet Audio Broadcasting enabled – Please listen to the audio via your PC speakers.

Questions can be submitted using the Live Meeting Question Manager.

NOTE: There will be a limited phone bridge to the first 50 callers if you are having audio problems.  Live Meeting Internet Audio Broadcasting (IAB) has been enabled, please adjust the volume on your pc to audit the session and submit questions via the Live Meeting Question Manager. 

Conference Call:  

Toll free: +1 (866) 500-6738

Toll: +1 (203) 480-8000

Participant code: 4785480

You may be wondering to yourself, what’s new about directory migration in the Transporter Suite?  Well, I’m glad you asked.  There were a couple of things that we were trying to accomplish in the area of directory.  First of all, it occurred to us that you might want to do a directory migration *before* you do a mail migration rather than have it stapled onto the beginning of MigWiz.  Well, we’ve separated it out into its own task, called move-DominoUser.  Second of all, our previous directory migration required an act of God (or a Domain Admin) to get things done.  We designed the permissions in this new task to allow Account Operators/Recipient admins to do their job.  On top of that, when you execute the migration, we’ve enabled you to create the target accounts with mailboxes (if you’re ready for your mailbox migration) or without mailboxes (if you want your mail to keep being delivered to Domino).  Finally, we’ve exposed all of this functionality through PowerShell, which makes this whole process easy to automate.  Your boss will think you were up working all night, but just between us…

     $SecureString = ConvertTo-SecureString –String P@ssw0rd –AsPlainText -Force

Get-DominoUser | Move-DominoUser –TargetOU Users –InitialPassword $SecureString

…will migrate all of your users from Domino to Active directory, creating any new users as Exchange MailUsers in the Users OU with an initial password of P@ssw0rd.  If it finds an existing user, it’ll just merge the Domino directory information for that user into the existing account and upgrade it to a MailUser if necessary.  You’re done!  Time for you to go have dinner.  Bon appétit!

--Jenna