We've been having a problem with one customer who was migrating their on-premises mail users into SmartCloud Notes, because they ade a mail template change in their on-premises environment after giving us "staging" replicas of some users' mail files. The DESIGN task on the users' on-premises servers updated their mail file designs from the template, and this change replicated to users' local replicas (MMRs in this case). When the users replicated their local mail files with the service, the on-premises design changes were more recent than the design on SCN, and "won" the replication conflict. This resulted in local mail replicas with a "mixed" design of design elements from two different templates.
End users don't have access to update the design of their SmartCloud mail files, but they're using their local mail files so still see the error messages resulting from this mixed design.
Our recommended measure to prevent this, is to turn off the DESIGN task on the users' mail servers (including clustered servers) and make sure you know about all server replicas.
Alternately, if customers don't want to turn off DESIGN, they can process the user mail files to prevent template updates by removing the "inherit from" template name, and scanning for design elements that inherit from a specific template. But turning off DESIGN is probably simpler and safer.
We're adding instructions to the on-boarding process to prohibit any changes to user mail files design after their replication to the staging server, and updating our training materials. We'll cover this in an upcoming partner call, but meanwhile, I thought I should mention it in case there any ongoing rollouts where it may be an issue.
Andre Guirard | 24 February 2014 12:07:38 PM ET | | Comments (0)