Transporter Suite contains a set of tools for migrations from both Lotus Domino Servers, and generic IMAP/POP sources. For Lotus Domino the suite contains a set of tools for Directory and Free/Busy interoperability between Lotus Domino 6 or 7 and Exchange Server 2007 and Windows Server 2003 Active Directory. In addition for Lotus Domino the suite contains migration tools to migrate users, groups, personal address lists, mailboxes, personal mail archives, and applications from Lotus Domino 5, 6 or 7 to Active Directory, Exchange Server 2007, and Windows SharePoint Services 3.0. For generic POP/IMAP servers the suite contains a set of tools to bulk migrate mailboxes from any generic email servers that support the POP3 or IMAP4 protocol to mailboxes in Exchange Server 2007
To download tool click here
1 comment:
Interesting. Thanks. By the way, as far as I know the minimal supported build number is 5.0.9, right? The nice thing is that the whole thing runs on PowerShell scripting. However it might still be its Achilles' heel as you are dependent on the PowerShell engine then. I heard about problems with migrating time zones. Time zones are weird things…
By the way, I found that when you work with PowerShell it usually helps when you add the debug switch into the command line. That allows revealing the stage when the command fails to run. By the way here's a nice tip showing how you can debug powershell scripts right within the Visual Studio. The other side of working with PowerShell for the time being is that technology of PoSh scripting is moving so that it may come to the point that some expressions that worked for version 1 will not work for version 2. However, it's nice that the tools get more effective in use. How do you find the new debugging features in PowerShell 2.0? I think they may help in developing a sophisticated code. What scares me more than configuration of server side is the following: Okay we migrate to new environment. What next? Right. We have to provision users with the client access. I scanned some info here and there and I see that there are various ways to do that. However, as far as I understand the most elegant one is to use desktop management. I know PowerShell is pretty scalable but I need something mode scalable. Something that won't get stuck because of management hassles. The reason why I started talking about debugging was because I found that you might be a core scripter and even then you won't be able to script a functionality from start to finish without needing to debug it. However debugging doesn't necessarily mean you will be debugging the implementation. It usually comes to the point that you have to debug your design when you understand that the that script worked for 99 users simply doesn’t work for the environment with 100+ users. I don't know why this happens but generally it turns out that you can't just handle the whole thing by just using $args or something… What's more, in a large environment you have to deal with Active Directory where you have to [ADSI]"LDAP://dc/ou=,…," and so on. Sure, when you configure Outlook - believe we will be using this client - you have to do that on the client. But all your clients are tightly connected with Active Directory environment and hence the need to have the client-side script to be AD-dependent. However with the lack of support of CDOEX and WMI in Exchange situation gets more pressing. Personally I am now thinking about the tool. Something like Desktop Authority
may do the trick. I've heard a lot about this tool from Scriptlogic before. Currently I am trialing it in my environment and the more I use it the more interesting it gets to develop a new approach of client-side mail access management in my Environment. For example I found that I can relocate user PST files and address book to a central server location placing them each into a separate folder dedicated specifically for a user that should be using these files. It always was a pain for me to configure separate environments for desktop and mobile users since you can't apply the same settings both for a roaming user and the static user that doesn't need to roam. Roaming profiles somehow do the trick to mitigate the problems with centralized document management but they are of no use for working with Outlook profiles. On my test environment I've been able to configure users by setting them with appropriate Outlook profile settings without needing to change settings mask in the registry or forcing the client part to run and wait for the user input. What I liked from my trials of this desktop management tool was the level of automation available for the client side. Not only it was easy for me to set different configuration options for users but it also was effective on the client side. The only thing that the user needs to do after the configuration is applied to him is to run Outlook on his desktop. It automatically connects to the right Exchange server so that I can even use different servers for users depending on their location or OU. And I can apply client-side configurations tuning them down to the user level! That really impresses when you know what it usually takes to configure such things through scripts.
Post a Comment