Problems Migrating Wiki Calendars

We upgraded a 10.6.8 server with several wikis to OS X Server 10.8.2. The wikis appear to have imported ok, except for the calendar information. When accessing the calendar page, an error is returned saying File Not Found.
There are no obvious errors in the migration log. If I make a new wiki, the calendar works ok on that wiki so I'm pretty sure CalDAV Server is working ok. 
I found the migrated data in a migration folder on the 10.8 server. I even found the wiki's .ics files tucked away in a subfolder. I could probably find a way to re-import those files if I could blow away whatever problem the migrated wikis have.
I've deleted the wikis, re-imported them (http://support.apple.com/kb/HT5082) from the old Collaboration folder and they come back with the same problem. Documentation on this product is pretty light. Does anyone have any beta on the relationship between the wikis and their calendars? If the migration won't work, I'd be glad to just reset the calendars and work on a way to import the .ics files.

Some further input. I have created a clone HDD to play with.
On Snow Leopard, I have done unbind from Active directory, set up Open Directory as a local master, change permissions on all wikis to have everyone read and write permissions without login.
then Reboot, checked that wiki is accessible without any password, then upgrade to Lion on that partition.
Everything went fine, but I still get same result.
There are no wikis in wikiserver.
When I check the info in /Library/Collaboration/Groups/ all info is there, also it is in /Library/Server/Wiki/FileData
But I still can't see anything when I launch wiki

Similar Messages

  • Migrating Wiki Calendars from Lion from Lion

    This was an information article, since I spent a few hours on this one and there was no documentation and may help someone one day!
    Description: This article was a guide on how to move a Wiki Calendar form a Lion server to another Lion Server.
    Problem: Wiki Calendar Service wasn't running properly, and the service was stopped / restarted and never came back on. There was a few errors on our XServ regurading this, but since there was no phone support, I created a work around by migrating the data to another mini, to get calendars back up and running. This may come in handy for someone to migrate servers.
    Another problem that came into factor here was also we upgraded from Snow Leapord, so instead of all of your files being in 1 place like they would be on a lion machine they were in multiple directories, which made the process more difficult.
    Process: A few steps will have to be done in order for this to work. As our configuration was binded to AD, in a multi domain forest. Also remember the wiki calendars are inbended into the wiki, so not only moving the calendar files are enough to get it working on a different machine.
    1) Bind to AD and get your 2nd machine up and running
    2) Migrate the Wiki Calendars over using the KB article on apples forumn. http://support.apple.com/kb/HT5082
    3) Copy the config files for the Calendar - I included the default folders for this below.
    /Library/Server/Calendar and Contacts/Data ---> /Library/Server/Calendar and Contacts/Data on the new server
    **note**
    If you came from a snow leapord machine you will have a folder called migrated-data / .calendarserver_version files stored in a different place, once found it will have to be copied to /Library/Server/Calendar and Contacts/Documents
    Both of these files need to be in this folder on the new server if your using the apple defaults ---> /Library/Server/Calendar and Contacts/Documents
    I also had renamed my calendars-migrated to calendars-migrated-old after they were moved to the proper location.
    The folder calendars-migrated will also have to be copied over via a USB drive since hidden attributes are embedded and any sort of network sync drops these files. (rsync / sftp) If you navigate into the calendars-migrated data, you will see filse like this with permissions drwxr-x---@ and you need to retain the @ if you have multiple calendars in 1 wiki.
    Once the folder calendars-migrated is moved to the new location in /Library/Server/Calendar and Contacts/Documents/ you will have to use a chown to change the ownership of the permissions for the calendars-migrated folder
    # sudo chown -R root:_calendar calendars-migrated
    4) Next we will have to export the database for caldav
    Stop the calendar / address book services
    # sudo serveradmin stop calendar
    # sudo serveradmin stop addressbook
    Export the Database to the /tmp folder (file will be called caldav.pgdump)
    # sudo pg_dump --format=c --compress=9 --blobs --username=caldav --file=/tmp/caldav.pgdump caldav
    Move the file /tmp/caldav.pgdump from the old server to the new server on /tmp/caldav.pgdump.
    One the new machine wipe the database so you can import it with the correct version (form moving the .calendarversion file over)
    # sudo dropdb -U _postgres -i caldav
    Create a new database on the new machine
    # sudo createdb -U caldav caldav
    Import that database to Collab so it can be used in the wiki
    # sudo -u _postgres pg_restore -d caldav -U collab --single-transaction /tmp/caldav.pgdump

    Hi,
    I'll just say my try of wiki migration from SLS(MacPro) to LS(MacMini with Internal Disk1&2).
    1)Fisrt I made a bootable backup of SLS to Disk2 of MacMini.
    2)Second I booted from Desk2.  MacMini was  running as SLS.  After that, I installed Lion and LS from App Store.
        Wiki migration was successful. So Disk1 is an original LS and Disk2 is LS with wiki migration.
    Good luck!
    Tac

  • Migrate wiki from MLS to MAVS

    Dear Folks,
    I want to provide a solution on how to migrate the Wiki from a Mountain Lion Server to a Mavericks Server. Both Servers are running but in different locations and they can't communicate directly with each other. Upgrading the MLS was no option - after what I had read in hundreds of threads. The MLS is a 10.8.5 (with the latest version of server.app up until the 15th of October 2013) and Mavericks a 10.9.1 (with the latest version of server.app up until New Years Eve).
    I hadn't done it without the help of Andreas from Metalab in Vienna (lovely Hackspace) - so the grace goes to him!!
    First things first - he isolated 2 issues on MLS - revolving postgresql Version AND Socket! Thank you Apple-developers you did a great job here - since this product is called „The Server for everyone“ I believe either the title is incorrect or some guys haven’t understood what the a server for everyone implies - since everyone isn’t a geek, nerd, developer etc. - think about it!
    Trying to connect to psql on MLS:
    bash-3.2# psql
    psql: could not connect to server: No such file or directory
              Is the server running locally and accepting
              connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?
    What?!
    bash-3.2# serveradmin status postgres
    postgres:state = "RUNNING"
    What?!
    So he started digging on MLS:
    bash-3.2# netstat -na|grep LISTEN
    nothing tangible here - nothing ist listening to 5432
    Dig deeper on MLS:
    bash-3.2# lsof | grep postgre
              #output omitted for clarity
    postgres_ 2546      _postgres   10u     unix 0xa319efaa0af41357       0t0         /Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432
    postgres_ 2547      _postgres   10u     unix 0xa319efaa0af3fbe7       0t0         /Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432
              #output omitted for clarity
    postgres_ 2548      _postgres   10u     unix 0xa319efaa0af3fa57       0t0         /Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432
              #output omitted for clarity
    postgres_ 2549      _postgres   10u     unix 0xa319efaa0af3f8c7       0t0         /Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432
              #output omitted for clarity
    postgres_ 3102      _postgres   10u     unix 0xa319efaa0b220357       0t0         /Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432
              #output omitted for clarity
    Hold the horses still - that got him thinking! How does that fit to the output of the psql-command just seconds earlier (and I literally mean seconds!) Can you see it?
    The truth is, the Socket is at:
    /Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432
    but is expected by psql to be in /var/psql_socket/.s.PGSQL.5432!
    Expected What?!
    Verified it again on MLS:
    bash-3.2# psql
    psql: could not connect to server: No such file or directory
              Is the server running locally and accepting
              connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?
    bash-3.2# psql --help
    Yep - when postgresql was compiled obviously somebody was sitting on his fingers - during implementation nobody had told psql the path for the socket at the "new" location?! Ergo - psql is looking for the socket in the default location - where it is not.
    Then, with the help, he managed it to get in.
    Trying to get in on MLS:
    bash-3.2# psql -p "/Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432"
    psql: invalid port number: "/Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432"
    Trying again on MLS:
    bash-3.2# psql -h "/Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432"
    psql: could not connect to server: Not a directory
              Is the server running locally and accepting
              connections on Unix domain socket "/Library/Server/PostgreSQL For Server Services/Socket/.s.PGSQL.5432/.s.PGSQL.5432"?
    And again - almost there on MLS:
    bash-3.2# psql -h "/Library/Server/PostgreSQL For Server Services/Socket/" -p 5432
    psql: FATAL:  role "root" does not exist
    Typo:
    bash-3.2# psql -h "/Library/Server/PostgreSQL For Server Services/Socket/" -p 5432 -u colab
    psql: invalid option -- u
    Try "psql --help" for more information.
    And - tata - he was in on MLS:
    bash-3.2# psql -h "/Library/Server/PostgreSQL For Server Services/Socket/" -p 5432 template1 collab
    psql (9.1.9, server 9.2.4)
    WARNING: psql version 9.1, server version 9.2.
             Some psql features might not work.
    Type "help" for help.
    template1=#
    Lets find the databases and roles on MLS:
    template1=# \l
                                       List of databases
           Name        |   Owner    | Encoding | Collate | Ctype |    Access privileges   
    -------------------+------------+----------+---------+-------+------------------ -------
    caldav            | caldav     | UTF8     | C       | C     |
    collab            | collab     | UTF8     | C       | C     |
    device_management | _devicemgr | UTF8     | C       | C     |
    postgres          | _postgres  | UTF8     | C       | C     |
    template0         | _postgres  | UTF8     | C       | C     | =c/_postgres           +
                       |            |          |         |       | _postgres=CTc/_postgres
    template1         | _postgres  | UTF8     | C       | C     | _postgres=CTc/_postgres+
                       |            |          |         |       | =c/_postgres
    webauth           | webauth    | UTF8     | C       | C     |
    (7 rows)
    And there are the roles on MLS:
    template1=# \du
                                  List of roles
    Role name  |                   Attributes                   | Member of
    ------------+------------------------------------------------+-----------
    _devicemgr | Create DB                                      | {}
    _postgres  | Superuser, Create role, Create DB, Replication | {}
    caldav     | Create DB                                      | {}
    collab     | Superuser, Create role, Create DB              | {}
    webauth    | Superuser, Create role, Create DB              | {}
    Aaaaah - so there is a role collab and a database collab! Lets connect to the "right" database and dive into it on MLS.
    template1=# \q
    bash-3.2# psql -h "/Library/Server/PostgreSQL For Server Services/Socket/" -p 5432 collab collab
    psql (9.1.9, server 9.2.4)
    WARNING: psql version 9.1, server version 9.2.
             Some psql features might not work.
    Type "help" for help.
    collab=# \d
                       List of relations
    Schema |            Name             | Type  | Owner 
    --------+-----------------------------+-------+--------
    public | blog_entity                 | table | collab
    public | document_entity             | table | collab
    public | entity                      | table | collab
    public | entity_acls                 | table | collab
    public | entity_acls_defaults        | table | collab
    public | entity_attrs                | table | collab
    public | entity_changesets           | table | collab
    public | entity_comment              | table | collab
    public | entity_lock                 | table | collab
    public | entity_preview              | table | collab
    public | entity_private_attrs        | table | collab
    public | entity_tag                  | table | collab
    public | entity_type                 | table | collab
    public | file_entity                 | table | collab
    public | filedata_entity             | table | collab
    public | filename_reservation        | table | collab
    public | global_settings             | table | collab
    public | groups                      | table | collab
    public | migration_entity            | table | collab
    public | migration_status            | table | collab
    public | migrationplaceholder_entity | table | collab
    public | notification                | table | collab
    public | page_entity                 | table | collab
    public | podcast_entity              | table | collab
    public | podcast_episode_entity      | table | collab
    public | preview_queue               | table | collab
    public | project_entity              | table | collab
    public | relationship                | table | collab
    public | savedquery_entity           | table | collab
    public | search_index                | table | collab
    public | search_stat                 | table | collab
    public | session                     | table | collab
    public | subscription                | table | collab
    public | user_activity               | table | collab
    public | user_entity                 | table | collab
    public | user_entity_favorites       | table | collab
    public | user_entity_read_status     | table | collab
    public | user_entity_unread_status   | table | collab
    public | user_entity_updates         | table | collab
    public | user_entity_watched         | table | collab
    public | user_readall_time           | table | collab
    (41 rows)
    That looks fantastic! Lets start dumping with some help through pg_dump --help and then issuing the following on MLS:
    bash-3.2# pg_dump -h "/Library/Server/PostgreSQL For Server Services/Socket/" -p 5432 -f /Volumes/USBSTICK/wikidatabase -U collab collab
    pg_dump: server version: 9.2.4; pg_dump version: 9.1.9
    pg_dump: aborting because of server version mismatch
    What?! How could that be?! The commands refer to an older version?!
    Start digging again on MLS!
    bash-3.2# which psql
    /usr/bin/psql
    bash-3.2# which pg_dump
    /usr/bin/pg_dump
    That's where I stepped in and told Andreas "Hey - ahm - I know of a path completely different…. /Applications/Server.app/.….". Thanks mate!
    Dig again on MLS!
    bash-3.2# /Applications/Server.app/Contents/ServerRoot/usr/bin/pg_dump --version
    pg_dump (PostgreSQL) 9.2.4
    Lovely - that one looks good - lets use it. All of that got us finally to the right command on MLS.
    bash-3.2# /Applications/Server.app/Contents/ServerRoot/usr/bin/pg_dump -h "/Library/Server/PostgreSQL For Server Services/Socket/" -p 5432 -f /Volumes/USBSTICK/wikidatabase -U collab collab
    There it is - the whole Database on the stick - finally - it took Andreas only 5 Minutes - approximately? I am just baffled.
    Then I copied the Folders from the /Library/Server/Wiki/FileData of the MLS to the exact same location on the MAVS and sat permission - navigating to /Library/Server/Wiki first:
    bash-3.2# chown -R _teamsserver:_teamsserver FileData/
    bash-3.2# chmod -R +a "_www allow read" FileData/
    I compared the the collab DB on the MLS with the MAVS collab DB to see the differences - BTW - the Socket has moved again on the MLS! Move up in this documentary and you’ll see on how to find it on MAVS.
    bash-3.2# lsof | grep 5432 
              #output omitted for clarity
    postgres_   382    _teamsserver    3u     unix 0x399cdd6eeea1efe1       0t0         /Library/Server/Wiki/PostgresSocket/.s.PGSQL.5432
              #output omitted for clarity
    bash-3.2# psql -h "/Library/Server/Wiki/PostgresSocket/" -p 5432 collab collab
    psql (9.2.4)
    Type "help" for help.
    collab=# \d
                       List of relations
    Schema |            Name             | Type  | Owner 
    --------+-----------------------------+-------+--------
    public | adc_device_entity           | table | collab
    public | adc_team_entity             | table | collab
    public | blog_entity                 | table | collab
    public | bot_entity                  | table | collab
    public | botgroup_entity             | table | collab
    public | botrun_entity               | table | collab
    public | build_agent_registry        | table | collab
    public | document_entity             | table | collab
    public | email_notification          | table | collab
    public | entity                      | table | collab
    public | entity_acls                 | table | collab
    public | entity_acls_defaults        | table | collab
    public | entity_attrs                | table | collab
    public | entity_auditlog             | table | collab
    public | entity_changesets           | table | collab
    public | entity_comment              | table | collab
    public | entity_lock                 | table | collab
    public | entity_preview              | table | collab
    public | entity_private_attrs        | table | collab
    public | entity_tag                  | table | collab
    public | entity_type                 | table | collab
    public | file_entity                 | table | collab
    public | filedata_entity             | table | collab
    public | filename_reservation        | table | collab
    public | global_settings             | table | collab
    public | groups                      | table | collab
    public | migration_entity            | table | collab
    public | migration_status            | table | collab
    public | migrationplaceholder_entity | table | collab
    public | page_entity                 | table | collab
    public | podcast_entity              | table | collab
    public | podcast_episode_entity      | table | collab
    public | preview_queue               | table | collab
    public | relationship                | table | collab
    public | savedquery_entity           | table | collab
    public | scm_commit_entity           | table | collab
    public | scm_server                  | table | collab
    public | scmrepogroup_entity         | table | collab
    public | search_index                | table | collab
    public | search_stat                 | table | collab
    public | session                     | table | collab
    public | subscription                | table | collab
    public | timeseries                  | table | collab
    public | timeseries_toc              | table | collab
    public | user_activity               | table | collab
    public | user_entity                 | table | collab
    public | user_entity_favorites       | table | collab
    public | user_entity_read_status     | table | collab
    public | user_entity_unread_status   | table | collab
    public | user_entity_updates         | table | collab
    public | user_entity_watched         | table | collab
    public | user_readall_time           | table | collab
    public | visible_entity_tag          | view  | collab
    public | wiki_entity                 | table | collab
    public | work_queue                  | table | collab
    public | work_schedule               | table | collab
    public | work_schedule_recurrence    | table | collab
    public | work_schedule_status        | table | collab
    (58 rows)
    Hmmm - 41 tables in the old, and 58 in the new. What am I going to do? To be able to roll back I dumped the MAVS DB before I would do anything else.
    I had to decide between trying to take the old MLS DB and just pg_restore it into the MAVS DB, or - trying to upgrade the MLS instance to MAVS. I was afraid doing the upgrade since the MLS was a mess. At the end I would decide to go for the latter - since I had dumps. It took a while but - hey - it worked. Everything in place! Wiki running - everything else, too! The database has now 58 tables - ok - lets dump it. Notice again - no need to specify the proper version of pg_dump, but the Socket has changed from MLS to MAVS - again - you could see this when I connected with psql as well!
    Please use (-F c) compression when dumping - otherwise you’ll receive a nasty error when importing it at the MAVS.
    bash-3.2# pg_dump -h "/Library/Server/Wiki/PostgresSocket/" -p 5432 -F c -f /Volumes/USBSTICK/MLSafterupgrade2MAVS_collab_db_compressed.pgdump -U collab collab
    I then copied the dump to the server - the Desktop of the administrativ account - I did it through screensharing which is accessible after establishing a VPN to the location the server resides in.
    Unfortunately the command for pg_restore has a different syntax then the pg_dump. Use pg_dump --help to see the details. I’ll explain it quickly:
    -c is to clean entries in the target tables (you must not use capital c)
    -d specifies the database into which you would like to restore
    -h specifies (again) where the DB is - the socket
    -p the port to use
    -U is the role that likes to work on the DB
    you must not use -f since it’s not needed
    bash-3.2# pg_restore -c -d collab -h "/Library/Server/Wiki/PostgresSocket/" -p 5432 /Volumes/OSXDATA/Users/macminiadmin/Desktop/MLScollabdb_compressed.pgdump -U collab
    pg_restore: [archiver (db)] Error while PROCESSING TOC:
    pg_restore: [archiver (db)] Error from TOC entry 2466; 2605 16639 CAST CAST (text[] AS public.hstore)
    pg_restore: [archiver (db)] could not execute query: ERROR:  cannot drop cast from text[] to public.hstore because extension hstore requires it
    HINT:  You can drop extension hstore instead.
        Command was: DROP CAST (text[] AS public.hstore);
    pg_restore: [archiver (db)] Error from TOC entry 1816; 2616 16636 OPERATOR CLASS hash_hstore_ops collab
    pg_restore: [archiver (db)] could not execute query: ERROR:  cannot drop operator class hash_hstore_ops for access method hash because extension hstore requires it
    HINT:  You can drop extension hstore instead.
        Command was: DROP OPERATOR CLASS public.hash_hstore_ops USING hash;
              #output omitted for clarity
    I saw quite a lot errors (some revolving functions etc.) - however, it worked. Wikis are present again on the MAVS. Not without the initial help of Andreas - thank you once again!
    I would like to recommend to everyone joining hackerspaces in their location. I do not know them in other areas - I can only speak for the metalab in Vienna. Fantastic place with fantastic, very knowledgable people. I would also recommend reading a book like PostgreSQL 9 Admin Cookbook - this helped me quit a lot as well. It’s available through various stores - virtual or real - choose what you prefer.

    Frustrated, not angry...
    Well folks. I think this is goodbye to OS X Server - the server that I thought was much easier to use.  I've followed instructions on this forum and several others over the past 7 months.  It's cost me so much time and headache.
    Migrating wikis from Mountain Lion Server to Mavericks server has yet to work
    Upgrading our Mountain Lion Server to Mavericks leaves us without wiki, calendar, and other services
    Apple support docs don't do the trick
    Phone calls with Apple support techs haven't provided any solutions.
    Our current Mountain Lion Server suddenly lost all filesharing authentication capability and Apple enterprise solutions haven't been able to figure this one out.
    I'm stuck with a server with broken mountain lion server I have never been able to upgrade and/or migrate and ultimately would be left to copy/paste wikis to a fresh Mavericks server, export/import calendars from each client station, and contacts - I don't even know how that's going to work.
    I believe in keeping IT folks employed, but...
    The support from Apple seems so marginal (just for the server) and the plethora of problems with upgrading to Mavericks server and/or the manual fight to only potentially get it done seems very un-Apple like and just downright counter to what Apple represents.
    So I'll think different...
    Our server will be relegated to a client machine with simple file sharing.  Perhaps We'll buy Daylite to assume some of the responsibilites.  Truth is, even when things were working, it was always flaky in some way.
    I really wanted to employ OS X Server in an efficient way, but it's been more trouble than I can accomodate.
    Fortunately I am not an average client user nor a novice, so working in terminal is comfortable.
    Perhaps in a few years or so, I'll reconsider, but my experience with OS X server on Mountain Lion and Mavericks has affected my trust.
    Thanks for all of the help to those who provided instructions, workarounds, directions toward solutions, etc.
    For those of you who had a successful migration - consider yourself lucky.
    ...by the way...after finishing the incredible instructions on this page (and i sincerely mean that despite them not working for me) the result was a wiki page that looked like this
    Caught exception "[<CSEntityPlaceholder 0x7fb2d15d5910> valueForUndefinedKey:]: this class is not key value coding-compliant for the key externalID." [NSUnknownKeyException] executing route /app-context/wiki/:
    0   CoreFoundation                      0x00007fff8a0fe25c __exceptionPreprocess + 172
    1   libobjc.A.dylib                     0x00007fff8da20e75 objc_exception_throw + 43
    2   CSService                           0x0000000104bc7957 -[CSLocalServiceProxy forwardInvocation:] + 1229
    3   CoreFoundation                      0x00007fff8a05c1c4 ___forwarding___ + 452
    4   CoreFoundation                      0x00007fff8a05bf78 _CF_forwarding_prep_0 + 120
    5   CSService                           0x0000000104bf9573 __27-[CSAppContextService init]_block_invoke240 + 180
    6   CSService                           0x0000000104bdf81a __53-[CSRoutingHTTPConnection httpResponseForMethod:URI:]_block_invoke + 95
    7   CSService                           0x0000000104be2d6c -[CSHTTPBackgroundResponse bounce:] + 286
    8   Foundation                          0x00007fff9073976b __NSThread__main__ + 1318
    9   libsystem_pthread.dylib             0x00007fff8bc58899 _pthread_body + 138
    10  libsystem_pthread.dylib             0x00007fff8bc5872a _pthread_struct_init + 0
    11  libsystem_pthread.dylib             0x00007fff8bc5cfc9 thread_start + 13

  • Web Based Wiki Calendar does not match iCal Account Calendars

    +Accidentally posted this in the 10.5 Server section, hopefully there's not a problem posting it here as well, but since I'm on 10.6.7 Snow Leopard Server I thought this section might have an answer:+
    Having a weird issue with a Wiki Calendar that I want to share throughout the office. I created a group and then created a Wiki for it using the Server Preferences, then enabled the Calendar in the Wiki Preferences. This works fine, calendar shows up when logged into the wiki.
    Next I wanted to have it accessible from both the Web for the few PC users we have and from iCal for our Mac users. I added the Wiki calendar with the following settings in iCal:
    Account type: CalDAV
    User name: shortname (of a group member)
    Password: (password of group member)
    Server address: server.mydomain.com/principals/wikis/groupshortname
    The calendar gets added fine in iCal with one problem, it is not the same calendar that is on the wiki if you log in via a browser. Events added in iCal do not show up on the wiki's events list and if I add a calendar or change the name it is not reflected on the wiki page either.
    The Server Path in iCal preferences shows:
    /principals/_uids_/wiki-groupshortname/
    Events that I add to the calendar will show up to everyone that has the account added in iCal, just not on the wiki page. Wondering if anyone else has come across this and knows how to fix it. Thanks.

    What I did is checking if one of the server updates causes the problem:
    - Clean installation of 10.6.3
    - New and empty folders for collaboration and calendar
    - Checking user calendar was fine - with the user wikis and calendar is no problem at all.
    Wikis:
    - New test-wiki and new calendar entry was as it should (in the calendar folder under the real wiki-name folder - not 465465464654645something)
    - Connecting with iPhone worked calender are updating
    - Connecting with iCal from OSX failed (could not find UID__4565465436135thing)
    - Updating the server with 10.6.6 combo
    - second test-wiki and new calendar entry was as it should (in the calendar folder under the real wiki-name folder - not 465465464654645something)
    - Connecting with iPhone worked calender are updating
    - Connecting with iCal from OSX ok and updating
    - I copied two of my production wikis in the collaboration folder and the calendar are updating with iCal and iPhone
    - Updating the server with 10.6.7 combo
    Without loosing a second the server is making new calendars and renames the Websites Name of the calender with 4653134604645065406something.
    - But only with the migrated wikis from 10.5 not with the new test wikis
    I will now make another installation and update to 10.6.6 only and try to reconfigurate the server.

  • Can I add more than one Wiki calendar to my web cal?

    Hi,
    I would like to add more than one Wiki-Cal to my Webcal (or CalDAV). Well I have two Wikis with calendars both are shown in my webcal (see photo)
    I have added the wiki calendar "Oberstufe" and from another wiki "Praktikum".
    In one Wiki I want to add a second calerndar "stundenplan". This works very fine (see photo)
    The problem is that I can't add this second calendar "Stundenplan" to my iCal calendars. The Link is added. When the mouse is over this link there is a hand. But pressing this link doesn`t work.
    Where is my mistake?
    I'm using OS Lion Server with an SSL-Connection and a selfsigned certificate.

    Hi,
    See my post here:
    https://discussions.apple.com/message/15253863#15253863
    Best wishes
    John M

  • Can you set a time range in the wiki calendar?

    I think the wiki calendar is a great feature in 10.5 Server, however I am annoyed by one problem. I can't figure out a way to limit the time on a wiki to say 8am to 5pm. I would like to use this as a class calendar page on the wiki, but it is really annoying to have to scroll through 24 hour days. Does anyone know a way to do this? It would be great if Apple allows us to edit the time being shown on the wiki.
    Thanks,
    David

    Hi,
    I don't have Leopard here to try it with the wiki, but with Tiger I can publish a user calender to the iCal server after setting the time period in iCal client preferences. The times out of range are greyed out. When I subscribe with a different Tiger client those same periods remain greyed out.
    Since Tiger can only read calendars I can't test the wiki interaction yet. This tells me that the iCal server can respect time periods once set.
    Another data point.
    Harry

  • "All Day Events" Do Not show up in wiki calendar

    Hello;
    Anyone find out how to solve this problem? I have a 10.5 ical server. Extensive use of calendars both individual and group. Users have access to wiki calendars from ical on their macs. The intention is to allow users of other operating systems to view wiki calendars however none of the all day events display at all on web page/wiki calendar.
    Thanks.

    Hm, I opened it up in Aperture once, but I recently (re-)arranged all events in iPhoto. I had the full hierarchy in there and did not work in Aperture. I just had to recreate the library and after that the events were gone.

  • Setting up Wiki Calendars in iCal with Active Directory Accounts

    I'm Having a little trouble wrapping my head around our Wiki Calendar Solution,
    Id like to find a way to get the 10.6 Wiki Server Calendar's in iCal Client - using our active directory authentication.
    I have a test 10.6 Server bound to our Active Directory with Wiki's up and running and am able to log in with AD account's and view and manage the Wiki Calendar - I can see how to subscribe to the calendar's - But I need full integration with iCal and maybe even Outlook - subscribing only provides read access.
    anyone have any idea how his can be accomplished in and active directory setting - my searches have lead me to OD solutions and thats not going to work.

    I don't know how much I'll be able to help, but I do have AD accounts using wiki services. Can you verify a few things:
    1. The AD group is listed in the "Wiki Creators" box in Server Admin, yes?
    2. If you open Terminal and run "sudo serveradmin settings teams:enableClearTextAuth", does it return "teams:enableClearTextAuth = yes"?
    3. If you open System Preferences -> Accounts and then edit the directory servers, does the AD domain show as working normally?
    Also, have you worked to isolate the problem? Have you tried creating an OD user to test against the wiki? Are the logs showing anything?

  • How to migrate the calendars for all users?

    At work we have two Mac servers, both running Mountain Lion. I'm looking for a way to migrate the calendars for all the users from server A to server B. I've recreated all the users on the new server, as there are problems with most users on the old server.
    I've seen some topics covering backing up calendar data on the server and seen some PostgreSQL related, but nothing seems to apply to Mountain Lion. How do I create a PostgreSQL dump of the calendars? I know I will have to edit the GUID's to make it work on the new server. Or is it as simple as copying the data from /Library/Server/Calendar and Contacts/ to the same location on the new server?

    At work we have two Mac servers, both running Mountain Lion. I'm looking for a way to migrate the calendars for all the users from server A to server B. I've recreated all the users on the new server, as there are problems with most users on the old server.
    I've seen some topics covering backing up calendar data on the server and seen some PostgreSQL related, but nothing seems to apply to Mountain Lion. How do I create a PostgreSQL dump of the calendars? I know I will have to edit the GUID's to make it work on the new server. Or is it as simple as copying the data from /Library/Server/Calendar and Contacts/ to the same location on the new server?

  • How to Subscribe to Outlook Calendar in Group WIKI Calendar

    Ok, here's what I've been trying to figure out how to do for about a year.  Our small office uses PC's with Outlook as our Calendar.  We are not on Exchange Server.  We are using Mac Mini Snow Leopard Server ver. 10.6.8. I'm trying to figure out a way so that our office can look at one central calendar and see individual calendars for each of the users.  I don't want all the users to have their events/appointments on 1 calendar because then you can't tell whose event/appointment it is.   I've setup a Group WIKI and have activated the Calendar and have a group consisting of the attorneys assigned to the Group.  Outlook 10 can publish its calendar as to a webdav server.  In fact I'm able to subscribe to my Outlook Calendar once its been published in the iCal client on the Snow Leopard server.  It updates in both directions when changes are made.  The problem is that when I go into the Group WIKI Calendar, although I can create calendars there and then PUBLISH them so they can be Subscribed to in either iCal or in Outlook 2010, I can't figure out how to SUBSCRIBE to a webdav/caldav calendar, ie. the Outlook 2010 that's been published, in the WIKI Calendar.  Thanks for your help.

    Hello,
    I'm afraid I'm not familiar with the specific intricacy of your situation (a hosted domain at Outlook.com), and so do not know if indeed that is causal to your issues. But perhaps a workaround will be useful? For example, if you indeed use your hosted domain for your email, but create a true Outlook.com account for the use of only Calendar and Contact synchronization, then that might work?
    You can find complete instructions here:
    http://supportforums.blackberry.com/t5/General-BlackBerry-10-Smartphone/How-To-OTA-Sync-BB10-and-non...
    For your email account, you simply use the domain they are hosting, and for Contacts/Calendar, the true Outlook.com account that you create for that purpose.
    Good luck!
    Occam's Razor nearly always applies when troubleshooting technology issues!
    If anyone has been helpful to you, please show your appreciation by clicking the button inside of their post. Please click here and read, along with the threads to which it links, for helpful information to guide you as you proceed. I always recommend that you treat your BlackBerry like any other computing device, including using a regular backup schedule...click here for an article with instructions.
    Join our BBM Channels
    BSCF General Channel
    PIN: C0001B7B4   Display/Scan Bar Code
    Knowledge Base Updates
    PIN: C0005A9AA   Display/Scan Bar Code

  • Lost Wiki calendars after upgrade to 10.6.4

    Hi,
    After upgrade my clients to 10.6.4 we are not be able to connect to our Wiki calendars using iCal client.
    The original path was:
    /principals/wikis/WIKI-NAME/
    But now it says the client is not able to connect to:
    /principals/_uids_/8a8be0fd-f969-5760-bef6-a73ad4ae3aa1/
    If we recreate the subscription, the first time iCal is able to access to the calendar data, using the original path, but after close and restart the client, it modifies the path and uses the new path value (/principals/_uids_/8a8be0fd-f969-5760-bef6-a73ad4ae3aa1/)
    In the caldavd error log says:
    [AMP,client] [twistedcaldav.directory.principal#error] No principal found for UID: 8a8be0fd-f969-5760-bef6-a73ad4ae3aa1
    We do not have this kind of problems with our Leopard (10.5.8) iCal clients or using the web page.
    Thanks in advance for any help.
    H.

    A followup from my post here: http://discussions.apple.com/messageview.jspa?messageID=11686666&stqc=true
    Looking at server debug error logs in Info mode, it appears that when querying for the group's HEX UID, the server does the following process:
    - Creates a wiki record for the GUID in Memcache; the correct data appears to be passed from the wiki entry
    - Checks state of GUID, fails to find it
    - Removes memcache data
    - Returns "Not Found" to the client
    Anyone know why the Twisted is failing to successfully create the Memcache entry?
    This is the log of the events dealing with the targetted UID:
    2010-06-17 11:00:40-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.wiki.WikiDirectoryService#info] Creating wiki record with GUID 4946e8b4-dbee-59aa-9064-37bc5ae59154
    2010-06-17 11:01:01-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.cache.MemcacheResponseCache#debug] Adding to cache: '04a59fceaad709e7fcbbe8a1a846fa43' = '((I0\nNtp1\nI5849565769670424107\n(I0\nNtp2\n(I207\n(dp3\nS\'Last-Modified\'\n p4\n(lp5\nS\'Thu, 17 Jun 2010 15:01:01 GMT\'\np6\nasS\'DAV\'\np7\n(lp8\nS\'1, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events, calendarserver-private-comments, calendarserver-principal-property-search\'\np9\nasS\'Content-Type\'\np10\n(lp11 \nS\'text/xml\'\np12\nasS"<?xml version=\'1.0\' encoding=\'UTF-8\'?><multistatus xmlns=\'DAV:\'>\\r\\n <response>\\r\\n <href>/principals/wikis/acgiit/</href>\\r\\n <propstat>\\r\\n <prop>\\r\\n <principal-collection-set>\\r\\n <href>/principals/</href>\\r\\n </principal-collection-set>\\r\\n <calendar-home-set xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/_uids_/wiki-acgiit</href>\\r\\n </calendar-home-set>\\r\\n <calendar-user-address-set xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/principals/wikis/acgiit/</href>\\r\\n <href xmlns=\'DAV:\'>urn:uuid:4946e8b4-dbee-59aa-9064-37bc5ae59154</href>\\r\\n <href xmlns=\'DAV:\'>https://server.redacted.tld:8443/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n <href xmlns=\'DAV:\'>https://server.redacted.tld:8443/principals/wikis/acgiit/</href>\\r\\n <href xmlns=\'DAV:\'>/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n <href xmlns=\'DAV:\'>http://server.redacted.tld:8008/principals/wikis/acgiit/</href>\\r\\n <href xmlns=\'DAV:\'>http://server.redacted.tld:8008/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n </calendar-user-address-set>\\r\\n <schedule-inbox-URL xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/_uids_/wiki-acgiit/inbox/</href>\\r\\n </schedule-inbox-URL>\\r\\n <schedule-outbox-URL xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/_uids_/wiki-acgiit/outbox/</href>\\r\\n </schedule-outbox-URL>\\r\\n <dropbox-home-URL xmlns=\'http://calendarserver.org/ns/\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/_uids_/wiki-acgiit/dropbox/</href>\\r\\n </dropbox-home-URL>\\r\\n <displayname>acgiit</displayname>\\r\\n <principal-URL>\\r\\n <href>/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n </principal-URL>\\r\\n <supported-report-set>\\r\\n <supported-report>\\r\\n <report>\\r\\n <acl-principal-prop-set/>\\r\\n </report>\\r\\n </supported-report>\\r\\n <supported-report>\\r\\n <report>\\r\\n <principal-match/>\\r\\n </report>\\r\\n </supported-report>\\r\\n <supported-report>\\r\\n <report>\\r\\n <principal-property-search/>\\r\\n </report>\\r\\n </supported-report>\\r\\n <supported-report>\\r\\n <report>\\r\\n <expand-property/>\\r\\n </report>\\r\\n </supported-report>\\r\\n </supported-report-set>\\r\\n </prop>\\r\\n <status>HTTP/1.1 200 OK</status>\\r\\n </propstat>\\r\\n <propstat>\\r\\n <prop>\\r\\n <xmpp-uri xmlns=\'http://calendarserver.org/ns/\'/>\\r\\n <notification-URL xmlns=\'http://calendarserver.org/ns/\'/>\\r\\n </prop>\\r\\n <status>HTTP/1.1 404 Not Found</status>\\r\\n </propstat>\\r\\n </response>\\r\\n</multistatus>"\np13\ntt.'
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: checking dir|guid|4946e8b4-dbee-59aa-9064-37bc5ae59154
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: miss dir|guid|4946e8b4-dbee-59aa-9064-37bc5ae59154
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Faulting record for attribute 'guid' with value '4946e8b4-dbee-59aa-9064-37bc5ae59154'
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] opendirectory.queryRecordsWithAttribute_list(<PyCObject object at 0x101b47670>,'dsAttrTypeStandard:GeneratedUID','4946e8b4-dbee-59aa-9064-37bc5ae 59154',8193,False,['dsRecTypeStandard:Users', 'dsRecTypeStandard:Groups', 'dsRecTypeStandard:Places', 'dsRecTypeStandard:Resources'],['dsAttrTypeStandard:GeneratedUID', 'dsAttrTypeStandard:RecordName', 'dsAttrTypeStandard:AltSecurityIdentities', 'dsAttrTypeStandard:RecordType', 'dsAttrTypeStandard:RealName', 'dsAttrTypeStandard:FirstName', 'dsAttrTypeStandard:LastName', 'dsAttrTypeStandard:EMailAddress', 'dsAttrTypeStandard:AppleMetaNodeLocation', 'dsAttrTypeStandard:GroupMembers', 'dsAttrTypeStandard:NestedGroups', 'dsAttrTypeStandard:ResourceInfo', 'dsAttrTypeStandard:ResourceInfo'])
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Failed to fault record for attribute 'guid' with value '4946e8b4-dbee-59aa-9064-37bc5ae59154'
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: storing (negative) dir|guid|4946e8b4-dbee-59aa-9064-37bc5ae59154
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.principal#error] No principal found for UID: 4946e8b4-dbee-59aa-9064-37bc5ae59154

  • Wiki calendar path!!

    Hi!
    I'm working on ical server, wiki calendar for group! As I know it is not possible to send invitation if calendar is based on wiki, but may be it is possible to change path for wiki calendar so it could look on calendar which made no server __uids__/<calendar> but not in __uids__/wi/ki/<calendar>!
    I suppose it could solve the problem with invitations, because if you have wiki calendar for group, and user uses this calendar also on ical (just by changing server path) you are not able to send invitations! But if it's regular calendar on ical server it can send invitations, so I just want to find where I can change path to calendar for wiki calendar!
    May be somebody have some ideas?
    Thanks in advance!

    While the behavior you describe
    (...every so often the Lion iCal client will forget the group wiki path and it seems to revert to the default ("/principals/__uids__/many hex characters"). I then have to go back in and restore the group wiki path...)
    is not ideal, I can't even get it to remember it once. Restart iCal server, restart iCal client, restart MacBook Pro with client...it keeps reverting back to the hex address.
    You mention something about
    ...this was a preferences problem with Lion iCal in the client...
    and
    ...I cleaned all the individual calendar files out of the Library folder...
    Can you be more specific? I tried digging through the library files, looking for ones associated with the URL of the SLS Wiki Calendar, but that did not seem to help.
    Thanks!

  • Wiki calendar pages can't be accessed

    After the most recent server and security updates, no one is able to access the calendars through the wiki web sites. Everything else on the sites are accessible but on the home page under "Upcoming Events" shows a message "Unable to access calendar, because an error occurred" and when we attempt to access the calendar, the page is grayed out and it is stuck at "getting events from server" with the spinning wheel. We are not using group calendars, just individual calendars through the wiki web pages. Is this happening to anyone else?

    Idem
    i just can't access the wiki calendar.
    But I can access calendars linked with individual accounts (from the "my page")
    i have some other issues with individual calendars in ical clients : randomly an connection error occurs, and most of time it takes loads of time to update at opening and/or after editing.
    I get this :
    +Le serveur a répondu+
    +« HTTP/1.1 500 Internal Server Error »+
    +à l’opération CalDAVRefreshDelegateListQueueableOperation.+
    I don't know if both problems are linked together or not.

  • Lion iCal client can't read SLS wiki calendar?

    Anyone else running Snow Leopard Server (10.6.8) having issues with the new Lion iCal client (v5.0) not seeing a wiki/group calendar? I've got the server path on the Lion client on a new MacBook Air exactly the same as that of the Snow Leopard client (v4.0.4) on my Mac Pro: /principals/__uids__/wiki-groupname
    The Mac Pro is working fine with this setup, only difference is the client OS/client iCal version.
    iCal server logs don't even show a hit from the Lion client when I refresh the client calendar, while it does show a hit from the Snow Leopard client when I refresh it.

    While the behavior you describe
    (...every so often the Lion iCal client will forget the group wiki path and it seems to revert to the default ("/principals/__uids__/many hex characters"). I then have to go back in and restore the group wiki path...)
    is not ideal, I can't even get it to remember it once. Restart iCal server, restart iCal client, restart MacBook Pro with client...it keeps reverting back to the hex address.
    You mention something about
    ...this was a preferences problem with Lion iCal in the client...
    and
    ...I cleaned all the individual calendar files out of the Library folder...
    Can you be more specific? I tried digging through the library files, looking for ones associated with the URL of the SLS Wiki Calendar, but that did not seem to help.
    Thanks!

  • Audtoschedule public wiki calendar

    I don't have a lot of experience with large or even medium scale networks. I am currently trying to set up a mac mini server with 10.6 .7. Honestly I am very frustrated so far with snow leopard server. Given the advertisement for this server software being "easy setup" it has been anything but. The documentation is thin at best and mostly nonexistent. DNS and DHCP have been the big culprits so far. But I digress. I am trying to create a public calendar of events for our church through ical server 2. My thought was to create a public wiki calendar and then use calendarserver_manage_principals in the command line to enable autoscheduling. Mainly so someone (myself most likely...) wouldn't have to accept every invitation. Unfortunately I get this error;
    Enabling auto-schedule for (users)publiccal is not allowed.
    Can anyone help me figure out what I can do to get this working? The calendar must be public so we can use a wordpress plugin for our website.
    Any help would be appreciated.

    Same here. been trying to fix for 3 days!
    10.6.7 on intel x-server. tried migrating old data, tried scrapping everything and starting from scratch. interestingly I have fixed the issue with personal calendars but the group calendars do not work. I tried 'matching' ssl settings. tried wiping /Library/CalendarServer and /Library/Collaboration (where group cal's seem to be)
    It seems group calendar support is falling through the cracks.
    [Wed Mar 23 16:36:50 2011] [notice] Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8l DAV/2 PHP/5.3.4 configured -- resuming normal operations
    2011-03-23 16:36:52-0400 [-] twisted.web.server.Site starting on 8086
    2011-03-23 16:36:52-0400 [-] twisted.web2.channel.http.HTTPFactory starting on 8087
    2011-03-23 16:49:25-0400 [-] [caldav-8010] [Uninitialized] [calendarserver.provision.root#error] Failed to look up wiki token (Connection was refused by other side: 61: Connection refused.)

Maybe you are looking for