Migrating Shared Calendars: Resources vs. Fake Users

[dNb]

Hi-
I'm working on migrating our users from the Sun Calendar Server to Zimbra and have two questions:

1. Can someone point me at a good comparison between "users" and "resources" as they are currently implemented? I understand that resources are essentially a special form of user with some auto-accept magic. I'm having a hard time finding information that would let me know when it would be better to use a resource vs. creating a fake user who shares out its calendar (the benefits/pitfalls of each approach, etc).
2. I can't seem to locate any information on how to import (e.g. an ics file) into a resource. The User Migration doc provides instructions for importing via REST into a user's calendar, but those URLs don't appear to work for a resource. zmprov sm calendar pru file.ics is also failing for me (status 500). Does anybody have a working example I can peek at?

Thanks!

-- dNb

[Chewie71]

Yes...we are migrating from the Sun Calendar system and would like to know how to migrate resource data as well.

Matt

[Rich Graves]

Great to see you here, dnb!

You can use the zimbra superuser account, default admin@zimbra.example.com, to post to resource users' service URLs. Import of a very large .Mac calendar worked for me (the IT department's vacation/sick time for the last 7 years). The URL for third-party posting might not be exactly correct in the User_Miration page, and quoting special characters can be tricky. I've posted a few such cases to the forums.

Resource accounts have no passwords and cannot be logged into directly, but admin web GUI "View Mail" works. That's the easiest way I found to delegate a resource user's calendar rights. Of course, you might be capable of hacking an appropriate zmprov wrapper in python or some other obscure scripting language.

If you want a department administrator to be able to actually log on as a resource user and enter/edit events and privileges and such as that user, then it's easier if it's a user. Normal multiple and shared password caveats apply. ZCS 5.0 is supposed to have better sharing support, making this need go away, mostly.

Resource accounts also behave slightly differently in the global address list. Basically, if you're inviting a resource to a meeting, you might need to know that it's a resource, not a user.

If you're using Network Edition, and given the .edu pricing there's no reason not to (I would recommend pre-paying as many years as your administration can stomach, in order to get a better discount and lock in the price), then users eat up license seats. Resources do not. That's not an expensive proposition for a .edu, but it might be for a small business.

[manish]

Hi,

Bug 13084 has been logged to clean up iPlanet data.

Do have a look at: Bug 13084 - Need migration utility to standardize calendar data exported by iPlanet before importing into ZCS

Regards,
Manish

[dNb]

Hi Rich-

Thanks for your response, it helps a great deal. Some follow up things:

I've asked some folks at Zimbra what the actual URL should be, I'll post it here as soon as I get that info. (edit: see subsequent post)

Originally Posted by Rich Graves

Resource accounts have no passwords and cannot be logged into directly, but admin web GUI "View Mail" works. That's the easiest way I found to delegate a resource user's calendar rights. Of course, you might be capable of hacking an appropriate zmprov wrapper in python or some other obscure scripting language.

This post: Resource manager seems to imply one could set a password and log into it if one really wanted to. (edit: see subsequent post if you are using external auth)

Originally Posted by Rich Graves

If you want a department administrator to be able to actually log on as a resource user and enter/edit events and privileges and such as that user, then it's easier if it's a user.

Besides editing privs (which I get), does a user who gets delegate rights process/experience differ when editing or entering events?

Last question: if licenses aren't an issue, is there a good reason to use resources in this case?

P.S. I was happy to see you were hanging around these parts as well. Just FYI, the second edition for the book on the obscure programming language (very funny!) is in the works.

[dNb]

Originally Posted by manish

Do have a look at: Bug 13084 - Need migration utility to standardize calendar data exported by iPlanet before importing into ZCS

Regards,
Manish

Thanks Manish! My read of the bug report is I really want to run our data through your Perl script to clean it up before importing. This doesn't surprise me given the Sun product. Any other gotchas I should be aware of?

Thanks!

-- dNb

[marcmac]

Originally Posted by dnb@ccs.neu.edu

Hi-
I can't seem to locate any information on how to import (e.g. an ics file) into a resource. The User Migration doc provides instructions for importing via REST into a user's calendar, but those URLs don't appear to work for a resource. zmprov sm calendar pru file.ics is also failing for me (status 500). Does anybody have a working example I can peek at?

Thanks!

-- dNb

Should work the same as any other account, or it does for me. Can you post your syntax?

[dNb]

Ok, with Marc's help (quotes from him below reproduced with permission), I think I'm getting a handle on all of this. Let me brain dump everything I have found so far so others can benefit from the much-appreciated assistance I received from him.

Difference between a resource and a user: (Marc says) Biggest difference is that a resource doesn't show up in a user search, and doesn't use up a license.

I also believe a resource gives you a little auto-accept magic. If you want to have a human or group of humans manually handle reservations and such, see Resource manager

If you want to POST via the REST interface to a resource you need to either use an admin access backdoor (my term, more on this in a sec) or make sure that you can log in to that resource. In my initial testing, this is what tripped me up because we are using an external authentication source.

Marc says there are three different ways to handle the external authentication to a resource:

• add the resource to your external auth source (in our case, an LDAP directory) like any other user
• set zimbraAuthLdapExternalDn for that resource to make it use a specific DN for its authentication. This gives you the benefit of setting that resource (and perhaps all of your resources if you so choose) to use the same DN for authentication and hence they all get the same password.

  zmprov ma resource@domain.com zimbraAuthLdapExternalDn someDN

• turn on zimbraAuthFallbackToLocal so that Zimbra will fall back to its local directory if there exists a password locally and the external directory does not have an entry for the resource.

  zmprov md zimbra.example.edu zimbraAuthFallbackToLocal TRUE
  zmcontrol stop
  zmcontrol start

If you don't want bother with authentication issues, you can bypass this by having the admin user authenticate instead on the admin port. So this means that your curl command could look something like this (replace resource with the name of the resource in question):

curl -u 'admin@zimbra.example.edu:passwd' --data-binary '@./file.ics' \
'https://server:7071/service/home/resource@zimbra.example.edu/calendar?fmt=ics'

Notice all of those nifty single quotes? Careful quoting is key to making sure this works and so I've quoted everything possible in the command line. Though I didn't need it, you may also need to explicitly specify the domain of the resource in question (hence my @zimbra.example.edu in the URL and in the user name).

If you'd like to learn more about automated calendar twiddling, I'd recommend also reading this thread started by the inimitable Rich Graves: Auto-provisioning calendar data/shared calendars.
That's where I found the clue to use the admin port.

Hope the above is as helpful to others as it was to me.

-- dNb