Running 10.6.4 client and server here.

A User's account was deleted from WorkGroup Manager when he took another job.

However, we forgot to have him purge his iCal events before his
account was deleted.


So, on the shared recourse calendars (like room reservation
calendars), if I go to clean up calendars from many, many months ago
where he created an event as the Invitee/organizer, if I try to
*delete* those events, iCal comes back with a "Revert to Server"
because (I'm assuming) there's no way to "notify the originator" any
longer.


Is there an option here for cleaning out those calendar items where
the "organizer" account is no longer a valid account?


Thanks!

- Steve
--
Sr. Systems Administrator | from which all the others proceed.
Office of Technology Transfer | -- Ayn Rand
_______________________________________________
___________________________________________________

Posted on the ICal-server mailing list. Go to http://lists.apple.com/mailman/listinfo/ical-server to subscribe.

At present the best answer is very much a workaround. There are a couple of 'good' ways to do this in the product, but none of these are implemented in Snow Leopard.

You'll need to create a dummy OD record with the same GUID as the de-provisioned user. At that point you should be able to do any necessary cleanup. We realize that there should be an easier way to do this, and it's 'on the radar'.

Cheers,
-dre

On Jun 17, 2010, at 9:32 AM, Steve Maser wrote:

> Running 10.6.4 client and server here.
>
> A User's account was deleted from WorkGroup Manager when he took another job.
>
> However, we forgot to have him purge his iCal events before his account was deleted.
>
>
> So, on the shared recourse calendars (like room reservation calendars), if I go to clean up calendars from many, many months ago where he created an event as the Invitee/organizer, if I try to *delete* those events, iCal comes back with a "Revert to Server" because (I'm assuming) there's no way to "notify the originator" any longer.
>
>
> Is there an option here for cleaning out those calendar items where the "organizer" account is no longer a valid account?
>
>
> Thanks!
>
> - Steve
> --
> Sr. Systems Administrator | from which all the others proceed.
> Office of Technology Transfer | -- Ayn Rand
> _______________________________________________
___________________________________________________

Posted on the ICal-server mailing list. Go to http://lists.apple.com/mailman/listinfo/ical-server to subscribe.

At 10:22 AM -0700 6/17/10, Andre LaBranche wrote:
>At present the best answer is very much a workaround. There are a couple of 'good' ways to do this in the product, but none of these are implemented in Snow Leopard.
>
>You'll need to create a dummy OD record with the same GUID as the de-provisioned user. At that point you should be able to do any necessary cleanup. We realize that there should be an easier way to do this, and it's 'on the radar'.
>
>Cheers,
>-dre


(I figured this might be what you suggested...)


However, since the user left ages ago (and his account was deleted many, many months ago) -- how can I determine what the GUID for his account was to recreate an account with that GUID?


- Steve
--
Sr. Systems Administrator | from which all the others proceed.
Office of Technology Transfer | -- Ayn Rand
_______________________________________________
___________________________________________________

Posted on the ICal-server mailing list. Go to http://lists.apple.com/mailman/listinfo/ical-server to subscribe.

On Jun 17, 2010, at 10:28 AM, Steve Maser wrote:

> ...
> However, since the user left ages ago (and his account was deleted many, many months ago) -- how can I determine what the GUID for his account was to recreate an account with that GUID?

One way to find the 'lost' GUID would be to grope the filesystem under the iCal Server document root.

The default location is /Library/CalendarServer/Documents, under which you should find __uids__. That directory is the top of a two-level hashing scheme based on the first four characters of the GUID (this hashing is done to keep the directory sizes reasonable if there are a lot of accounts). So you could for example do a recursive grep from the __uids__ directory.

For example (from within the __uids__ directory):

grep -r "ORGANIZER;CN=Andre LaBranche" .

This returns a list of paths to events that I have organized. Crack one of those open, then examine the ORGANIZER property. The GUID for the user is shown as the last element of this property, probably split across two lines. It is bolded below (and randomized for my protection!)

3F-850D-A2FC997FF23C

When creating the dummy account, it would probably be a good idea to use the same full name (first and last name) as well as the exact GUID.

Cheers,
-dre

>
>
> - Steve
> --
> Sr. Systems Administrator | from which all the others proceed.
> Office of Technology Transfer | -- Ayn Rand

>> ...
>> However, since the user left ages ago (and his account was deleted many, many
>> months ago) -- how can I determine what the GUID for his account was to
>> recreate an account with that GUID?
>
> One way to find the 'lost' GUID would be to grope the filesystem under the
> iCal Server document root.
>
> The default location is /Library/CalendarServer/Documents, under which you
> should find __uids__. That directory is the top of a two-level hashing scheme
> based on the first four characters of the GUID (this hashing is done to keep
> the directory sizes reasonable if there are a lot of accounts). So you could
> for example do a recursive grep from the __uids__ directory.
>
> For example (from within the __uids__ directory):
>
> grep -r "ORGANIZER;CN=Andre LaBranche" .
>
> This returns a list of paths to events that I have organized. Crack one of
> those open, then examine the ORGANIZER property. The GUID for the user is
> shown as the last element of this property, probably split across two lines.
> It is bolded below (and randomized for my protection!)
>
> 3F-850D-A2FC997FF23C
>
> When creating the dummy account, it would probably be a good idea to use the
> same full name (first and last name) as well as the exact GUID.


This would be where Apple actually making a proper calendar setup that
allows for administrators to actually clean up user detrius would not suck.
Of course, iCal would have to understand more complex permissions than
EVERYTHING and NOTHING. So , probably the fifth of never.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions

At 11:00 AM -0700 6/17/10, Andre LaBranche wrote:
>One way to find the 'lost' GUID would be to grope the filesystem
>under the iCal Server document root.
>
>The default location is /Library/CalendarServer/Documents, under
>which you should find __uids__. That directory is the top of a
>two-level hashing scheme based on the first four characters of the
>GUID (this hashing is done to keep the directory sizes reasonable if
>there are a lot of accounts). So you could for example do a
>recursive grep from the __uids__ directory.
>
>For example (from within the __uids__ directory):
>
>grep -r "ORGANIZER;CN=Andre LaBranche" .
>
>This returns a list of paths to events that I have organized. Crack
>one of those open, then examine the ORGANIZER property. The GUID for
>the user is shown as the last element of this property, probably
>split across two lines. It is bolded below (and randomized for my
>protection!)
>
> 3F-850D-A2FC997FF23C



Got back to this today. When I do this, I'm not apparently getting
a *full* UUID:


Starting here:

/Library/CalendarServer/Documents/calendars/__uids__


I do this:

root# grep -r "ORGANIZER;CN=" .

But I get (among others) these results:


:ORGANIZER;CN=;EMAIL=:urn:uuid:C02F1E31-0A69


That's it for the UUID: C02F1E31-0A69


I'm not cutting/pasting badly -- every line ends with that short "uuid" value.


Am I missing something obvious?


Is there anything just keeping me from deleting the .ics file in the
path? There are maybe about 100 of them where the is
the ORGANIZER, so it's not an impossible task, but I don't know if
that's the right way to approach this or not...



- Steve

--
Sr. Systems Administrator | from which all the others proceed.
Office of Technology Transfer | -- Ayn Rand

On Jun 18, 2010, at 10:43 AM, Steve Maser wrote:

> At 11:00 AM -0700 6/17/10, Andre LaBranche wrote:
>> One way to find the 'lost' GUID would be to grope the filesystem under the iCal Server document root.
>>
>> The default location is /Library/CalendarServer/Documents, under which you should find __uids__. That directory is the top of a two-level hashing scheme based on the first four characters of the GUID (this hashing is done to keep the directory sizes reasonable if there are a lot of accounts). So you could for example do a recursive grep from the __uids__ directory.
>>
>> For example (from within the __uids__ directory):
>>
>> grep -r "ORGANIZER;CN=Andre LaBranche" .
>>
>> This returns a list of paths to events that I have organized. Crack one of those open, then examine the ORGANIZER property. The GUID for the user is shown as the last element of this property, probably split across two lines. It is bolded below (and randomized for my protection!)
>>
>> 3F-850D-A2FC997FF23C
>
>
>
> Got back to this today. When I do this, I'm not apparently getting a *full* UUID:
>
> Starting here:
> /Library/CalendarServer/Documents/calendars/__uids__
>
> I do this:
> root# grep -r "ORGANIZER;CN=" .
>
> But I get (among others) these results:
> :ORGANIZER;CN=;EMAIL=:urn:uuid:C02F1E31-0A69
>
>
> That's it for the UUID: C02F1E31-0A69
>
>
> I'm not cutting/pasting badly -- every line ends with that short "uuid" value.
>
>
> Am I missing something obvious?

Yes :) As I mentioned, the grep returns the list of files. You must then look inside one of those files to find the full GUID. The grep output includes the path to the matching file, a colon, and then the line containing the match. Open the file at the displayed path to see the full contents.

-dre

>> This returns a list of paths to events that I have organized. Crack one of those open, then examine the ORGANIZER property. The GUID for the user is shown as the last element of this property, probably split across two lines. It is bolded below (and randomized for my protection!)
>>
>> 3F-850D-A2FC997FF23C

At 10:49 AM -0700 6/18/10, Andre LaBranche wrote:
>Yes :) As I mentioned, the grep returns the list of files. You must then look inside one of those files to find the full GUID. The grep output includes the path to the matching file, a colon, and then the line containing the match. Open the file at the displayed path to see the full contents.
>
>-dre


Doh!

That's what I get for trying to do this on a late Friday afternoon...


However, is there any reason I just couldn't delete the .ics files generated by the "grep" command...


Or would that break something else?


Thanks!

- Steve
--
Sr. Systems Administrator | from which all the others proceed.
Office of Technology Transfer | -- Ayn Rand
_______________________________________________
___________________________________________________

Posted on the ICal-server mailing list. Go to http://lists.apple.com/mailman/listinfo/ical-server to subscribe.

On Jun 18, 2010, at 12:24 PM, Steve Maser wrote:

> So, restoring the UUID in a dummy user account worked. I was able to delete all of the user's "personal" calendar information which then allowed me to delete the resource calendar links as well.
>
>
>
> I have a follow-up question: likely, there were many calendars created where all that happened was the user account was deleted in WGM when the user left the building and the user never cleaned out his/her personal server calendar prior to departure (I know now I should do this...)
>
>
> Is there a way to determine other "orphaned" events/calendars so I can do the same dummy account creation/calendar deletion procedure?
>
> (I fully realize the .ics files aren't taking up much space and with no account to go with them, they likely aren't hurting anything -- but if I'm in clean-up mode now, I'd prefer to clean it up fully...)

We don't have anything for Snow Leopard that does this, however such a tool has been developed and is sitting in our SVN repo, but is not tested / qualified for Snow Leopard. It works against trunk, but that code is substantially different from Snow Leopard, so it probably wouldn't 'just work' if you tried to run it as-is against a snow server.

For now I would recommend doing only as much cleanup as is necessary to remove the visible / annoying clutter. Save the thorough cleaning for a time when there's a tool that can do it for you in a supported fashion. There should be no harm in letting the orphaned data lay around for a while longer.

-dre

On Apr 28, 2011, at 12:24 PM, Steve Maser wrote:

> I'd like to revisit this thread from back in June 2010 and see if anybody has any suggestions:
>
> Way back in Feb 2009, somebody must have created a test server account and invited me to an event that I can't delete from my calendar now.
> ...
> However, if I stop/start the iCal server -- I can add the "262 Visitor" account to another instance of iCal (and add events to that calendar), but I am still unable to "decline" this particular event.
>
> Any suggestions about the best way to clean this up? Should I just stop the iCal service and trash the .ics file?

If you don't care about the event or whether it is removed from other people's calendars (if any), you can simply delete it on the server. It's not ideal, but should get it off your calendar.

> Stop the server and somehow *edit* the .ics file so I can decline that event (if so, how do I need to edit it?)

It's not clear why you can't decline / delete the event, though I suspect it's got something to do with the deleted / recreated originator principal. iCal client debug logs or perhaps the server's error.log may have a clue.

In general the problems with de-provisioned calendar principals are not easy to solve without specialized tools; these tools exist in our trunk code but cannot be easily used (yet) on Mac OS X Server if you are running iCal Server in the supported configuration.

-dre _______________________________________________
Do not post admin requests to the list. They will be ignored.
iCal-server mailing list (iCal-)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/ical-server/shu.mcknight%40zeusmail.org

This email sent to
)