If you're in trial with us now we've told you about it.
If you get a trial from us and this is relevant we'll clue you in on what to do.
But basically you will split up your migration into two runs: the "Current" and the "Historical" -- and for each run you want different keywords. Why? So that if something goes wrong in the second run you can remove only THAT data and not the data you inserted before. At Sumatra we're always looking out for you guys.
For historic data, we recommend inserting without sending email invitations – the process will go faster and you will still have the guest list in everyone’s appointments. Use this setting:
It’s like “printing” your calendar into Exchange.
So the meetings are not live meetings (but they’re historical so – what’s the problem?) – but everybody’s who had a meeting or appointment in their calendar will have it in their calendar post-migration.
One other thing: For testing using the date range in ocalreader's "Calendar Selection Dates" configuration option is fine.
For a production run, use OCS's UNIICAL date ranges to specify the date ranges in your ICS files. Why? You ask. Fair question.
If we interrogate the date and get a null answer in a migration into production, we’re spending cycles checking when we could be inserting. This inefficiency adds up over lots and lots of data.
Final word: be careful managing the keyword.
No comments:
Post a Comment