Consolidating your Domino Environment After Migrating to ExchangeJune 5, 2013
When Enterprise organizations make the move from Domino messaging to Exchange messaging, more often than not, a number of Domino applications are left behind. Unfortunately, not all Domino Applications are easily moved over to other platforms and quite often the legacy Domino infrastructure is still distributed. There are challenges associated with centralizing these applications and updating the workstations at the client level.
Sure, Domino has built in tools that can do the moves for you, but these tools have limitations and issues. AdminP is a great tool, but it simply creates the replica and you still have to update the Administrative ACL and add the replica to cluster members. Then, to redirect the workstation, there’s an additional challenge. You must add a redirector to the old application and hope users access it in a timely manner. This does not, however, remove references to the old server icons.
Lastly, there’s the issue of server schedule agents. When developers build agents, the agents are typically set to run on a particular server. Depending upon the purpose of the agent, it may not be able to run on all servers. As a result, when you move your applications to a centralized server, you’re still left with the schedule agents’ changes. Finding them all becomes a challenge, and then determining which ones are set to run on servers is the next obstacle.
But there’s a solution that can help you address all of these issues …it’s calledDomino Consolidator.
Domino Consolidator finds all applications and validates that they’re ready for migration. This check involves ensuring the Administrative Account has access to the applications. It also means auditing these applications for Consistent ACL Settings, enabled/disabled Replication, Server Encryption, Administrative Server settings, and many other aspects. All of these items can significantly affect the ability to move the application. In addition to first identifying potential problems, the tool can also correct a number of issues before the move happens.
If you recall earlier, I mentioned that AdminP would not address the creation of replicas on Cluster member groups. Well, Domino Consolidator can do this. If the application is to be moved to a clustered set of servers, replica stubs are created on both servers. Then the primary server is replicated with the original server, and the cluster replicator updates the other cluster members. This ensures that failover and redundancy are maintained.
So, now let’s discuss how to address your client workstations. After working with Domino for over 16 years, there's one thing I’m sure of …Domino Administrators will have no idea what icons or bookmarks are on an end users’ workstation. How can workstations be updated without knowing what is there? Well, adding icons is easy, but being able to dynamically address what icons and bookmarks a user has is more challenging. By sending a simple email with an embedded form and a button, the Domino Consolidator will actually read the desktop8.dsk and determine which icons are on the users’ workspace. In addition, Domino Consolidator will read the bookmarks.nsf to determine these as well. Adding a new server icon is also simple. The desktop8.dsk will provide a database replica ID on the original server. Now, we simply open using the replica ID on the destination server. If the database is there, Domino Consolidator will add the new server icon. Most importantly, all references to the database on any other server can be removed. Domino Consolidator will also redirect the replication of local replicas to continue working with the new server for any local replicas of applications, and it will also email back a log of all changes made on the workstation. This is then sent back to Domino Consolidator for reporting purposes. For this process to work, and in order for the email sent to be sent to the user, organizations will need to deploy Binary Tree’s CMT for Coexistence with ZApp product.
Lastly, we have the scheduled agents. Finding which agents run on what servers and then which servers the agents are set to run on is difficult. Typically this is a manual process. WithDomino Consolidator, however, the tool will analyze the newly consolidated applications footprint on the destination servers for the server-based agents. The tool can easily use an agent to make these agents run on the destination server. All of this simplifies the consolidation process for server-based agents.
In summary, Domino Consolidator allows organizations to minimize their dependency on their legacy servers. By consolidating servers down to smaller footprints, organizations will see a significant savings, as there will no longer be Domino licensing fees, server and software maintenance costs, and utilities and administration overhead.
Binary Tree’s Domino Consolidator will also help organizations save money in the long run. For example, an organization with 3,500 users, with 400 applications to consolidate, and with approximately 30 minutes to spare per workstation, the cost to gather information, update security, update agents and update workstations is over $126,000. Domino Consolidator ensures your Domino consolidation project takes significantly less time and costs about $625 in administrative costs.
To learn more about how to consolidate your Domino environment, attend ourwebinar on June 11, 2013 titled “SMART Guidance for Consolidating Domino After a Migration”.
You can also download a free cost avoidance calculator for Domino domain migrations from our website.