If your organisation is planning an upgrade from ND6.x and uses Mail-in Databases (based on the standard mail file template) for room or resource calendars etc., then beware that in ND7 and later, Busytime has undergone a very subtle but important change . . .
Now, instead of processing both Mail files and Mail-in Databases, in ND7 and later, Busytime will only processes the former. This means that following any upgrade, Busytime information will no longer be collected and displayed for Mail-In Databases.
To prevent this potential issue from occuring, simply create a new Person Document using the the same name, file path etc., as per the original Mail-in Database Document, and then delete the now superfluous Mail-in Database Document.
I think, in this case you would have to pay for additional licences, wouldn’t you?
Maybe I am missing something, but:
Why collect busytime info for mail-in databases?
If it’s for Rooms & Resoruces, the new RnRMgr takes care of that (but you do need to upgrade design of the Resource databases to the new Design.
Fred
@Thomas – yes you are absolutely correct. However this workaround will enable a post-upgrade transitory period, during which time, the information in these calendars can be migrated to the new RnRMgr facility. Once migrated, the associated Person Documents can then be removed.
@Fred – in the past, I’ve seen stand-alone calendar files (without any associated Person or Mail-in Database Documents) used for simple room booking management because of inherent issues with the old R&R (pre-ND7) implementation. In addition, by making these stand-alone calendars Mail-in Databases, it is then possible to perform busytime look-ups again them and check for availability, thus providing very similar functionality to the old R&R system.
The new RnRMgr functionally is significantly better, and I agree that it totally elevates the need for these stand-alone calendars, however it can become a time consuming and complex task, to not only migrate all of the calendar data across, but also to educate users about the changes. In my experience, this can only practically be performed after the upgrade (ie once the new RnRMgr is available), as a follow-on piece of work. I trust this now makes a little more sense?
“I think, in this case you would have to pay for additional licences, wouldnt you?”
Actually, I’m certain you wouldn’t. Accounts created solely for administrative and functionality purposes do not require a license. This is very clearly stated in the licensing rules from IBM. That’s why you don’t have to license development signature IDs, or LDAP logins, or special accounts for LEI, or anything that’s not associated with a *person*. You are required to buy licenses for human beings, be they employees, contractors, vendors, partners, suppliers or customers. You are not required to buy licenses for computers.
@Nathan – Thanks for clarifying any potential licensing issues.