Binary Tree would like to welcome Joel Greenwell as our guest blogger. Joel is the owner of
Pearbrook Management Consultancy in the United Kingdom and is an expert information technology and services consultant. Joel, along with Pearbrook, provides personal consulting services, and will works to help customers discover new business opportunities, reduce costs, and improve efficiencies wherever possible.
Clients always want to maximise the efficiency of their infrastructure, and this is especially true with migration projects to a new Exchange environment.
One particular project that I recently worked on started with a Lotus Domino environment that had 8TB of mail data, and the challenge was to migrate all 3,500 users to an Exchange installation that had only 4TB of storage in total. Before I go any further, the client was also implementing an archive solution on Exchange, so this wasn’t going to be an
impossible exercise, but more of a clever execution of migration techniques and leveraging the capability of advanced features in the
Binary Tree migration products.
Knowing what Binary Tree’s software tools are capable of, I came up with the concept of SNAP and DELTA, a two-stage migration methodology that staged a partial migration of data to the new Exchange platform, and then at a later date allowed for the final cutover of the users and their remaining data. The SNAP stage of data migration focused specifically on migrating email content delivered to a users’ mailboxes up to 6 months prior to being switched over to Exchange and Outlook.
The DELTA stage of migration covered all the remaining mail, calendaring, and contact data and was performed when users were actually being switched between email environments.
Microsoft Exchange environments are dependent on log files for their operation, and when migrating large amounts of data, there are plenty of log files being generated. SNAP migrations allowed us to manage the generation of log files, thereby ensuring Exchange was always available during the course of the DELTA migrations.
The SNAP migration also allowed us to assess the performance of the new Exchange environment with live data, not only with the delivery of service to end users, but also impact of tertiary activities such as Indexing, Backup, Archiving, and Anti-Virus scanning of content. Thereby we could address any issues encountered with the Exchange environment and underlying architecture (Virtual Machines, Server Blades, SANs etc) with genuine data with no risk to the business.
READ MORE >>
Today's blog post was originally posted on June 21, 2011 on Perry Hiltz's wildly popular blog, Domino Diversions. As most of you may know, Perry is a Solutions Architect at Binary Tree and a long-time
IBM Domino solutions expert. Today, Perry is heavily involved
in the success of Binary Tree's pre-sales, technical, and support teams, and focuses primarily on educating and supporting customers during their Microsoft Exchange migrations.
The thought of renaming a Domino Server is a daunting task at best. There are innumerable considerations to address when undertaking this task. There is the server security, groups, connection documents, mail-in-databases, access control lists, and not to mention the user desktop icons. As I continue to work with various organizations, the thought of Domino server virtual clustering has proven to be a way to simplify some of these processes.
The concept entails an Enterprise version of Domino. The administrator will still need to register a new server in the Address book. This will be the new name of the server. Then the next step is to create a cluster with the old server name, then the new server name. Once the cluster directory and cluster replicator tasks are initiated, the cluster directory database will contain cluster information for only the old server. 
The next step involves the creation of agents to scan all ACL’s to add the new server entry. Beware of roles, the agents will likely not associate the new server listing with any roles the old server had. Then connection documents to and from the old server need to be copied, and modified to use the new server name. Similarly group membership of the old server will require the new server to be added. Next will be to copy and paste, then modify all of the mail-in-database names. This will need to reflect the new server name. Once all of these aspects are in place, then the server’s Notes.ini can be modified to use the new server ID file for serverid= and keyidfile= to use the new server ID file.
READ MORE >>