Educational Institution Adopting Zimbra

I am a system admin at a Community College and would like to know if there are any kludges that would fill a few voids in my roadmap to adopting Zimbra for our student email system.

1. Is there a way for someone to 'self-register' once they have validated against a backend system (ie. Active Directory or LDAP), so that students can set up their own email accounts after being validated?

2. I am sure this is probably on the roadmap, but a script/job/admin function that could delete users that have had no activity in XX number of days?

3. (Really from left field).. Ability to receive/send appointments to the Groupwise 6 mail system. I can send the format of the outbound/inbound appointments if that would help :)

I am not a programmer/coder, so tackling some of these projects is beyond my ability - I am just curious as to whether or not they are do-able with the existing Zimbra (should I be able to kidnap one of our programmers), or whether I would have to wait for a later release before pushing ahead with the project. I do a lot of server side scripting, so if there is some sort of API that I could pass info to for authentication, adding users, etc. then I could probably tackle it myself - more documentation would be a great boon.

BTW, I am very impressed with the ease of setting up Zimbra to authenticate against a variety of sources - usually AD authentication in our environment is a bugaboo, but Zimbra handled it like a champ. I think this project will be a real winner.

BTW: Our current documentation is located at:
http://www.zimbra.com/downloads/index.php

Quote:

---

1. Is there a way for someone to 'self-register' once they have validated against a backend system (ie. Active Directory or LDAP), so that students can set up their own email accounts after being validated?

---

Take a look at:
http://www.zimbra.com/downloads/zimb...e.html#1022509

This zmprov is a script that shouls make it easy to pass arguments to to create accounts on the fly. Once idea would be have a simple webpage that auth'd the user's then call this script to add them to Zimbra prior to redirecting to the Zimbra login page.

Quote:

---

2. I am sure this is probably on the roadmap, but a script/job/admin function that could delete users that have had no activity in XX number of days?

---

There's no tool for this, but there may still be a way to script this. I'll check.

Quote:

---

3. (Really from left field).. Ability to receive/send appointments to the Groupwise 6 mail system. I can send the format of the outbound/inbound appointments if that would help :)

---

We send standard ical. Have you tried sending one? Not sure the groupwise format but if they support ical it should work. If it doesn't work can you send the examples with the results of your test.

Quote:

---

Originally Posted by dmcushing

2. I am sure this is probably on the roadmap, but a script/job/admin function that could delete users that have had no activity in XX number of days?

---

There are 2 ldap attributes that can be used for this - one is a config attribute, zimbraLastLogonTimestampFrequency - which controls the frequency of update for the zimbraLastLogonTimestamp, which is an account attribute. zmprov gacf will show the config attributes, and zmprov ga <account> will show the account attributes.

How this works: When you log on, the current time is compared to the zimbraLastLogonTimestamp. If the difference is less than the zimbraLastLogonTimestampFrequency (default 7 days) then the last zimbraLastLogonTimestamp is updated. (We do this to cut down on writes to ldap on logon). So, in essence, the frequency attribute controls the granularity of the logon timestamp - it will be no more accurate than the frequency value.

So, to expire accounts that have been inactive for X days, in a system with the timestamp frequency set to 7 days, you'll want to search for all accounts that have a logon timestamp older than X+7 days.

Quote:

---

Originally Posted by dmcushing

I am not a programmer/coder, so tackling some of these projects is beyond my ability - I am just curious as to whether or not they are do-able with the existing Zimbra (should I be able to kidnap one of our programmers), or whether I would have to wait for a later release before pushing ahead with the project. I do a lot of server side scripting, so if there is some sort of API that I could pass info to for authentication, adding users, etc. then I could probably tackle it myself - more documentation would be a great boon.

---

Code:

---

#!/usr/bin/perl

my $days = $ARGV[0];

$days = 30 unless (defined $days);

my $now = time();
my $lastMonth = $now - (60*60*24*($days+7)); # $days + 7 day expiry

my @s = localtime($lastMonth);

#YYYYMMDDDhhmmss
my $lastStamp = sprintf ("%04d%02d%02d%02d%02d%02d",
        $s[5]+1900,$s[4]+1,$s[3],$s[2],$s[1],$s[0]);

print "Expiring accounts idle since $lastStamp\n";

open ACCOUNTS, "/opt/zimbra/bin/zmprov gaa |" or
        die "Can't open accounts: $!";
my @accounts = <ACCOUNTS>;
close ACCOUNTS;

chomp @accounts;

foreach (@accounts) {
        my $st = `/opt/zimbra/bin/zmprov ga $_ | grep zimbraLastLogonTimestamp | sed -e 's/zimbraLastLogonTimestamp: //'`;
        chomp $st;
        $st =~ s/Z$//;
        if ($st < $lastStamp) {
                print "Expiring account $_: $st\n";
                #`/opt/zimbra/bin/zmprov da $_\n`;
        }
}

---

This should do what you want. NOTE - I've commented out the actual delete account line - please test this before you run it :)

Support like this is exactly what I was looking for - I am going to push forward with a small pilot project with Zimbra to get the ball rolling at our institution. I am sure I will keep everyone updated as I progress and have more questions, thanks much for the quick and direct answers.

I found this old thread while searching for "GroupWise." Refreshing because I could imagine this being useful to people, and it took a lot of time for us to find this.

The beta GroupWise migration utility is documented at:

http://www.zimbra.com/docs/ne/latest...llation_guide/

There are several open issues in bugzilla, the most significant probably being RTF/HTML attachments being migrated as Text.htm attachments rather than multipart/alternative, and calendar item time zone information being lost (it always to the migrating machine's time zone).

Both of the above issues appear to be handled by manual imapsync or iCal export/import work, but that's *a lot* more work. Only the GW migration utility appears to handle addressbooks well. Neither .NAB (CSV) not vCard do entirely the right thing with the hierarchical "Organization" addressbooks supported in GW.

Unresolved issue for us: How to migrate "Archived" mail. GroupWise has "Archive mail older than N days" functionality similar to Outlook, where older mail is removed from the server and stored exclusively on the client, in proprietary GroupWise format. We have people who have been using various versions of GroupWise for more than 10 years with very significant amounts of locally stored mail that we'd like to keep.

As for iCalendar/iTIP meeting request coexistence: GroupWise, even version 7.0.1, cannot handle recurring events. When GroupWise receives or imports a properly formatted vCal/iCal event with recurrence, only the first instance is seen. The rest are silently lost. This is a general problem with GroupWise that also affects interoperability with Novell's own Evolution client.