No. If you want to use a desktop client configuration as the basis for the initial setup of your Nomad client, the Nomad Web Migration action works very well for that purpose. However, you cannot currently use Nomad Roaming to persistently synchronize between a desktop client with Nomad.
There are a number of technical reasons why persistent sync is either difficult or impossible, but what it mainly boils down to is the desktop client has a lot of Eclipse settings that are very sensitive to changes in the Notes client configuration, and since those settings don't exist on Nomad clients you would quickly end up with partial backups that would break Eclipse.
We are looking at options for providing some level of rich client-to-Nomad sync in the future, but we're not there yet.
No, those backups are separate from each other and they cannot be mixed. Nomad Roaming backups only come from Nomad clients, and Web Migration backups only come from desktop clients.
Yes, but if a migration backup and a roaming backup are both in the Analyze DB for a user, the roaming backup will "win". Here's how that works:
Backups are saved to the Analyze DB at client startup (if needed), and at a backup interval defined in the Nomad Roaming action. See Nomad Roaming Setup and Examples for more details.
However, a backup only happens if something changed on your client. This saves a lot of bandwidth, so duplicate backups aren't created and uploaded unless they need to be. Also, backups don't happen while the client is idle or running in the background.
Ideally the Nomad client would also get backed up at shutdown, but unfortunately web browsers and mobile devices don't give much (or any) notice to an application when an app is closed, so we have to rely on scheduled backups to keep the data in the Analyze DB current.
This means that if you open a Nomad client, quickly make changes to the workspace (e.g. add or remove databases), and then close it immediately, there is a good chance that your changes won't have been saved to a new backup.
But that's usually okay! Because the next time your Nomad client starts up, it will check to see if there are any newer backups in the Analyze DB, and as long as no other Nomad clients made new backups for you in the meantime, your changes will remain in place and they will be immediately backed up.
The relationship between recent apps, desktop icons, roaming, and MarvelClient actions can be a little complicated. Normally this would only happen when you are using two Nomad clients simultaneously, they are out of sync, and one of them had a lot of changes and/or database open events between backups.
Here are some scenarios where a recent app might disappear. We will assume that you have two Nomad clients that share a backup, referred to as Client #1 and Client #2.
In general they play very nicely together by default. As long as the actions that change the workspace (e.g. move or delete icons, set workspace properties, etc.) have a runtime that happens after the Nomad Roaming runtime, the workspace change actions will operate against any changes to the workspace that have been roamed. In other words roaming will happen, followed by the workspace changes.
However, if you change the Nomad Roaming setting "Perform first roaming" to "in the background after startup", it's possible that roaming can overwrite the MarvelClient changes in certain situations. Be very careful using this setting, the default of "immediately at startup" is usually much safer.
With MarvelClient actions of course!
This will enable the Synchronize Contacts entry on the Replicator page and enable it to run automatically. It will even work at the initial startup of your Nomad clients!
Creating new Certificates in the local names.nsf requires a "Run Agent" action and a specialized agent. This needs to be customized for each situation, and customers can contact panagenda support for more information.