Blog Archives
SmartCloud Tip #7: Notes BUILT-IN tool for migrating to SmartCloud
Want a simple method for migrating mail to SmartCloud? Maybe you are interested in moving to a Service-Only configuration, but were told you couldn’t migrate the data? Maybe you already completed a migration in a hybrid environment only to find one mailbox that was missed and needs to be migrated after the migration specialist is gone?
This process is embarrassingly simple and could make migration tools obsolete, at least for smaller environments. This puts self-service migrations in the hands of the end user. It could eliminate many billable hours transferring mail for Certified Data Transfer Managers (DTM) like myself. But I believe in things like Open Source software and Sharing Knowledge for the greater good.
Use Archiving. It’s that simple.
The steps are so easy an end user could do it. Here are the details:
Overview:
Adjust the ACLs of the mail files as necessary.
Create local replicas of the old mail file and the new mail file.
Setup Archive settings in the old mail file to archive into the local new mail file.
Archive Now. (This step will delete everything from the local replica of the old mail file, so don’t let it replicate back to the server in case you need it for some reason.)
Replicate the new mail file back to SmartCloud.
Review the old mail file to ensure all documents were archived.
The details:
1. If you are going to switch to a Service-only environment, you will be getting a new Notes ID. Make sure it has access to your old mail file. This step may need to be done by the system administrator.
2. Open your old mail.
3. Create a local replica of it. It Must not be encrypted. If you already have a local replica that is encrypted, you will need to make a new one.
4. Uncheck the box on the replicator page to replicate it. This will keep it from replicating the deletions back to the server after you archive.
5. Repeat steps 2,3, & 4 for your new mail file in SmartCloud.
6. Open the local replica of your old mail file.
7. Pull down Actions – Archive – Settings…
8. Click on the Criteria tab. Disable any criteria that have a check mark indicating they are enabled.
9. Click the Create… button.
10. Enter a name for this criteria, something like “Move to SmartCloud”.
11. Check the box to Enable this Criteria.
12. In the field to select what should happen, browse to and select the local replica of your new SmartCloud mail file. The dialog will look like this:
10. Click the Selection Criteria button.
12. Leave the setting to “not modified in more than”, and change the period to 0 days.
13. Click on OK to all of the boxes. If the following dialog pops up, click yes.
14. The Scheduling settings will be displayed. Click OK without enabling the schedule.
15. You are now ready to perform the archiving. From the inbox of your old mail file, Pull down Actions – Archive – Archive Now.
16. When it is complete, you can check the document count in the database properties. It should be close to zero.Check the All documents view and in your calendar check the Lists – Calendar Entries view for documents that didn’t get brought over. It may be easiest to just re-create calendar entries.
17. Review the folders and calendar in the new mail file. When you are satisfied with the documents in the new mail file, go back to the replicator page and enable it so it can replicate to the SmartCloud server.
That is the whole process in a nutshell. There are some potential obstacles, like connection speed to the Internet, mail file size and Private folders. Also, you may also prefer to have someone with experience to turn on and configure your SmartCloud environment and address some other architectural details, but the act of moving your data can be incredibly simple. I have helped companies use this method very successfully. If you want help with the process, contact me at Divergent Solutions.
See the full list of tips HERE.
SmartCloud Tip #05: Problems for mail and calendar delegates. You’ll get tons of helpdesk calls if you don’t do this.
One of the points IBM stresses during your migration to SmartCloud is to migrate delegates of mail files, calendars, and contacts either ahead of or at the same time as the people who delegated them (delegators). This is necessary because a user cannot access databases on the SmartCloud servers until their own account has been added to the service. This is part of the security model. In other words, mail files in the service can only be viewed by users that are in the service. No problem. As you build your batches for migrating, the migration process alerts you who the delegates are for the people in a given batch and those delegates can be added to the same batch with one click.
But what is missed is that the delegates have bookmarks and calendar overlays pointing to the delegators mail or calendar. Those bookmarks point to the servers on-site, not in SmartCloud. So as delegators are migrated to SmartCloud, the old links that other people have to their mail don’t get updated. The end result is that delegates will continue to view the old data in the database on the server on-site even after the delegator has moved. The delegate gets no warning that the delegator has moved. The only clue is that they no longer see any changes that are made in the delegators’ mail or calendar. What makes this more insidious is that the problem begins when the DELEGATOR is moved, not when the delegate is moved. So an administrative assistant that manages many executives’ mail files has to constantly monitor when those executives are moved and then update their bookmarks.
That is why it is a best practice to be sure to promptly delete mail files from the on-site servers after their owners are successfully migrated. Life for delegates can also be simplified if all of the mail files that a delegate has access to are moved in the same batch. Then the delegate can update all the bookmarks at the same time. You could go a step further by creating database redirects as the databases are deleted from the servers on-site. If you do this, you don’t have to alert the delegates every time a delegator’s mail file is moved to SmartCloud. However, this can’t be done if you just approve the database deletions posted in adminP as part of the migration process. You need to create these some other way. One method is to delete the databases manually in the admin client where you can also add the redirect when it is deleted. You could also do this programmatically with an agent. I invite any developers to post a comment on the details for doing that.
I have posted an idea in IdeaJam requesting an enhancement.
as well as in Greenhouse.
SmartCloud Tip #03: Important Details to Setting the ACL on your Mail Files
When you move to SmartCloud Notes, you get many great benefits, but of course there are a few tradeoffs. One of those is giving up Manager access to the mail files. Whether you’re the mail file owner or the system administrator, the best access you’ll ever have is Editor. And unless you explicitly configure it otherwise, by default only the mail file owner will have any access at all. This is actually great for enforcing best practices. Users should never have more than editor access anyway, and in countries like France, the law prohibits administrators from accessing a user’s mail without their permission. Yes, the owner can always use delegation to grant others access to their mail file, but that only works if they are available to give that access. That doesn’t help for employees that are out sick or no longer employed at your company.
If you want anything other than the default, you need to plan ahead because once the mail file has been migrated, you can’t change the ACL. This means adding certain groups and roles to the ACL of the existing mail files as well as to the template for any future mail files.
There are typically 3 groups you will want to add to the ACL. The first is your administrator group. Without this, administrators can’t perform some basic administrator tasks, like opening the mail file to do troubleshooting.
The second group that may need access are support personnel who may need access to the mail files, but should not be included in your administrator group. For example, this may be regional administrators, or designated people on the help desk, or HR, or the legal department. How you organize these groups will vary depending on the organization and size of your company. Note that you need a different mail template in SmartCloud for each different ACL. For example, you will need a different template for each region if each region will have a different group of regional administrators.
The third consideration is providing access for your application servers in the event you have applications that run agents that directly touch the mail files. Keep in mind that no agents can run on directly on the SmartCloud mail servers so any agents will need to be run on a server you maintain on site. Typically databases use mail routing to get things into your mail file, but I have encountered a few applications that add entries directly to the calendar. The process of assigning access to these groups is simple, but must be done in advance of migrating the mail files into SmartCloud and also requires modifying the ACL of your mail template that will be posted in SmartCloud so future accounts created in the cloud will have them.
First, create a role called ExcludeDelegate in the ACL of the mail files, then create the three groups mentioned above as you need and apply that role to them. (More on exactly how to do this later.) The following screen shot was taken from the database catalog and shows these ACL entries framed in red boxes. Note that regardless of what level of access you give these groups in the mail file on site, it will not have more than Editor when it is moved to the cloud. But if those entries do not have the ExcludeDelegate role applied, they will be removed entirely from the ACL upon migration.
Entries needed in SmartCloud ACL
So how do you get these settings applied to all of your mail files in advance? You could add the entries using the administrator client. On the files tab, select a set databases then right click and choose Access Control – Manage. A dialog box displays that allows adding, modifying, or deleting ACL entries. It also allows creating roles. But the ability to actually applying those roles to ACL entries is missed. (I say BUG, IBM says “functioning as designed”) So the only way to assign a role to an ACL entry via the Administrator UI is to manually open each database one at a time and add the role to the entry. Not exactly convenient when trying to assign the [ExcludeDelegate] role to entries in hundreds or thousands of mail files before migrating them to SmartCloud.
Footnote: An SPR# GPKS6TNBN4 is a request to fix the admin client to mass-update roles in ACLs. Read this article for more details:
http://www-01.ibm.com/support/docview.wss?uid=swg21264880
Please take a moment to open a ticket with IBM technical support and request that your company be added to this SPR. The more companies that request an enhancement, the more urgent they consider it.
Meanwhile, you can accomplish this using third party tools, such as Ytria EZ ACL tool, a module in the suite of useful admin tools. (Contact me for a discount code) or you can write an agent to accomplish this task.
Prepare your environment with these steps well in advance of migrating and things will be much less complicated at the time of migration.
If you found this tip helpful, you might also be interested in my other tips:
SmartCloud Tip #01 Using the Notes admin client to compliment the SmartCloud web admin screens
SmartCloud Tip #02: Best Practices to get mail files ready to move to SmartCloud
SmartCloud Tip #02: Best Practices to get mail files ready to move to SmartCloud
Here are several essential tips to avoid users having problems after migrating users’ mail to SmartCloud and to avoid having problems during the migration.
1. First, make an initial pass with the Onboarding Planning Tool (OPT) as early in the migration planning process as possible. You will want to get a jumpstart on fixing all the errors it is going to find that you never knew you had. This will also help to identify all those orphaned accounts no longer in use so you can get a more accurate count of how many licenses you need.
2. Look at the mail files on your server with the admin client. Sort them by size. If you have any over 5 GB, then open each and see how many documents are in the inbox. If you have a lot of these, make an agent to scan them all and create a report. For any that have more than about 1000 messages in the inbox you should have the owner clean it up before they are migrated. This is a performance issue.
3. Identify all mail files that have more than 400 folders. These will need to be reduced to under 400. Again, it is a performance issue and can also cause errors. Finding these isn’t as easy. If you are a glutton for punishment, you can do it manually. Open the server log, go to the view Usage – By Size. Open the document for one of the mail databases and you will find a list of all the folders. An easy way to count them is to copy the list and paste it into a spreadsheet or into an editor that will display line numbers, like Notepad++, a great, free editor. I recommend creating an agent or using a 3rd party tool like Ytria tools instead. (Contact me and I can get you a discount.)
In case you’re wondering, I’ve already asked IBM to add processing counting the inbox documents and the number of folders to the OPT. It is more likely to happen sooner if others request it too.
4. If you aren’t already using local mail replicas and managing them with MMR, then you are best off getting this setup on all users before you start migrating. You can do it after the migration as well, but creating the replicas will take longer because it is pulling it down from the Internet instead of from servers in your data center. Do NOT try to do it at the same time you migrate users. You will inevitably have problems and it will give the impression the migration was the cause. For users with excessively large mail files or with a high document count in their inbox, create the local replica first and have them do their clean up work locally. If you use the MMR settings on the Mail tab of the Desktop Policy settings, you can also tell it to create the full text index automatically too. Your users will be thankful. Be sure to teach them how to use it too!
These tips aren’t documented in the IBM SmartCloud Wiki.
But there are many good lessons to learn there if you are considering making the move. Check out the Learning Center pages on the SmartCloud wiki
The Notes Guy in Seattle 