HT5139 OSX server failed, need to migrate wiki from TM backup to a different existing (configured) server

I've looked and found many responses involving restoring from time machine to restore the complete server. In this case, I have a TM backup of the failed wiki machine and a second running (and configured) server. What I need to do is restore the wiki from this first TM backup to the "new" server.... but only the wiki data.
Currently, the "new" machine is NOT running wiki services at all.
Both machines were / are running Mountain Lion, so there should be no issues there.
I'm having some trouble locating a procedure for this. Any help is appreciated, and apologies in advance if I missed these instructions on some other post!
Thanks in advance for all the help!

Does http://support.apple.com/kb/HT5082 help at all? You would have to restore your TM backup to a separate disk, use that to startup, dump the wiki and postgres data to disk, reboot using your new server disk and follow the instructions to copy all wiki data to the new server.
Cheers
Gerry

Similar Messages

Migrating wiki from Leopard Server (10.5) to Lion Server

Is there any way to migrate Wiki Server data from Leopard Server (i.e. 10.5 not 10.6) to Lion Server without upgrading to Snow Leopard first. I'm happy to set up everything else afresh but I've migrated wiki data before and it was a nightmare.
The situation we'll soon be in is needing to migrate wiki data on a PowerPC mac running Leopard Server to a new Power Mac pre-installed with Lion Server.

From: http://images.apple.com/macosx/server/docs/Upgrading_and_Migrating_v10.7.pdf
Need to set up Lion Server first, then:
Copy the wiki data located in /Library/Collaboration/ by default or in the location specified in Server Admin on the v10.5.8 or later server to a local volume Lion Server can access.
Use the following steps to manually migrate your Mac OS X v10.5.8 or later server’s Wiki data to Lion Server.
If you are migrating a v10.5.8 wiki server’s data, make sure Lion Server is bound to the same Open Directory master as the v10.5.8 server, so the ACLs for wikis can convert. If not, wikis are only readable or writeable by admins, and ACLs must be reset.
To migrate wiki data:
1 Start Wiki service in the Server app.
2 Enter the following command.
sudo wikiadmin migrate -r /path/to/collaboration/folder

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

Clean install OSX+S 10.9 then migrate data from 10.6 Server?

Howdy All,
I've had OSX Server from the first release but stopped at Snow Leopard Server waiting for the "new server" to mature a bit. I think it is time now to move to OSX Server 10.9 but also for a clean install to clear out the crud that has collected over all these years.
I have two main partitions: one for the OS with the Mail store and Wikis and another for user home directories and other files. Again this is going from Snow Leopard Server 10.6.last to 10.9 Mavericks and then Mavericks Server
My question is: If I clean install Maverick and then Mavericks server on another partition will I be able to migrate data and services over manually?
Of course, I will need to setup users and directory services again from scratch (but that is part of the plan to clean out the unused stuff that has collected over the years). I don't mind setting up fileshares, Web sites, DNS, and similar again.
However, when this is done will I be able to copy the mail store (i.e. all users email) over and will it be detected, updated if needed, and work? Similarly, when I copy over the wikis, will they be detected, updated if needed, and work?
Further, when I setup the symbolic links for home directories again (onto the other partition), will the home directories be updated (if needed) and work? I'm not sure what could have changed with regards to home directories but you never know.
In summary, I guess my question is about what migration only happens when you update as opposed to what happens when an older version of a resource or service is detected after an update. Hopefully there is more of the latter than the former.
Thanks in advance for any thoughts on this.
Cheers,
Ashley.

Out of your services (AFP/SMB, Mail, OD, SWU, and web), the one with the most potential for disaster and headache is clearly mail. If you are using the same host device, cutting services over in pieces will not be possible. However, here are some suggestions and potential points of concern.
AFP/SMB file services are cake. The only thing you need to consider is the potential time to copy the data if you are moving it to new disks. The other issue will be user's GUID values and the associated ACLs. Let's take the following scenario based on what you've detailed.
• You have data on /HDD/Shares/ and you are planning on moving them to the SSD. Is the SSD drive large enough to accept this data?
• If you had a share /HDD/Shares/Data and this contained an ACL allowing the design group to have access, the design group from the 10.6.8 OD may have a different GUID than the one you create on the 10.9.1 system. If this is the case, you can purge all ACLs with a sudo chmod -R -N /path/to/data. (Server.app should remove and then add but older versions resulted in merged messes so I go nuclear on the old settings) Then you can apply your new ACLs and allow the permissions to propagate.
• If you are leaving the data were it is, you will simply need to reset permissions. However, note that if you are exporting and then importing users (via an OD backup or via standard record format) then you are maintaining GUID and should not need to touch any permissions.
Regarding SWU, I would suggest looking into Caching server. If you are moving the entire environment to 10.9 and iOS 7, SWU is no longer needed. Caching server is easy as pie, requires no client configuration, and is more economical on your internet connection and server storage requirements.
Web is pretty easy also. But, this is dependant on what you are doing with web. If html/php/perl then you pretty much just move your site folders and you are up and running. If you were using MySQL, note that Apple replaced it with Postgres. You can either perform a conversion from MySQL to Postgres or you can just install MySQL again manually. The choice is yours. If you are not doing database backed sites, the migration should be cake.
OD is one of those technologies that I always prefer to start clean. In really large environments, this can be very tough due to passwords. You can export an OD backup from 10.6 and attempt a restore in 10.9.1. If you have a lot of MCX in 10.6.8, you may run into some trouble as Apple has deprecated MCX in 10.8 and above. However, this ensures that you have everything, from password to GUID. Test, test, and test some more if you go this route. An alternate option, especially if you are embracing the move away from MCX and to Profiles, is to do a user and group export for 10.6's Workgroup Manager. This will not provide passwords but it will provide editable text files of your account data. You can strip out the MXC and other legacy values and then use the resulting file to import users into a clean 10.9.1 OD master. Once again, you will not get passwords unless you add them to the import file. You need to figure out how many accounts and how sensitive users are to password resets.
The final piece is mail. This is the one area I have very little experience. I've been burned by Apple's mails solutions from way back in the AppleShare IP days and now make it policy to use anything else but Apple's mail solution. In a perfect world, moving the mail data store to the new OS and triggering Server.app should be enough. But Apple + mail never seem to enter the realm of a perfect world.
And finally, make sure DNS is correct before you do anything. Since you are dealing with mail, you should also shut firewall port forwards to prevent new mail from coming into the server while you work on the migration. Nothing worse than stitching mail together after a blown migration attempt.
R-
Apple Consultants Network
Apple Professional Services
Author "Mavericks Server – Foundation Services" :: Exclusively available in the Apple iBooks Store

Migrating wiki from 10.5 to 10.6 server

I am having trouble migrating my wiki from my leopard server to snow leopard server. This is the process I am doing.
1. create wiki group on snow leopard server with the same name as group on leopard server and turn off web service.
2. copied folder from /Library/Collaboration/group_name from 10.5 server to same location on 10.6 server.
3. edited ownership permissions to teamsserver:teamsserver on copied folder and sub-folders
4. rm index.db
5. edited GenereatedUID in the metadata.plist to match the GenereatedUID in Workgroup Manager for the group I created.
I am able to log in to the wiki and it takes me to the welcome that we have from the 10.5 server. The sidebar headings are the same. The problem is that I cannot see any of the entries or wiki pages that were created before. Is there something that I'm missing?

Here are the steps to manually migrate a wiki from 10.5 to 10.6:
sudo serveradmin stop teams
sudo mv $GROUP_DIRECTORY /Library/Collaboration/Groups/
sudo chown -R 94:94 /Library/Collaboration/Groups/$GROUP_DIRECTORY
sudo rm /Library/Collaboration/dataVersion.plist
sudo rm /Library/Collaboration/globalIndex.db
sudo rm /Library/Application Support/Apple/WikiServer/directoryIndex.db
sudo serveradmin start teams
You will then need to navigate to the wiki as an administrator and set the access permissions in the wiki's settings screen. There you can restrict access by directory users and/or groups (if you need that level of granularity).

I need to migrate data from Lion to OSX do you know of any problems with content between the two systems?

I'm using a MacBook AIR and OSX 10.9.1. When I upgraded that I made a mistake with the user name and so created another user. Now I understand I need to migrate the data between the two systems but that there might be trouble with some of the content files transferring across? Has anyone done this before? If so what were the pitfalls? Thanks and Help! No-one typing this feels as if they're on a steep learning curve at all!

Hi nothpole
Welcome to BlackBerry Support Forums
Sorry to hear that you're having issues with your BlackBerry ! Before trying anything else can you try check a few setting or undo it on your device ?
northpole wrote:
I have memory cleaning scheduled to run every 1 hour.
First advise is to disable Memory Cleaner ! you don't need that , It can cause freezing and clocking. To disable it , From your homescreen go to Options > Security > Advance Security setting > Memory Cleaner > Disable that feature .After disabling it reboot your device do it by removing the Battery while your device is Powered On then wait for at least a minute then reinsert it back, your device may take a long reboot .
Then monitor your device for the next few hrs. and check if you feel the same problem .
let us know.
Click " Like " if you want to Thank someone.
If Problem Resolves mark the post(s) as " Solution ", so that other can make use of it.

Migrating Wiki from MoinMoin

Our current wiki runs with MoinMoin and I want to migrate the information to the Mac OS X 10.5 Server wiki service. Does anyone know of a convenient way to import the MoinMoin files into Mac OS X (or export them from MoinMoin to Mac OS X 10.5 friendly format)? I don't need a full blown automagic solution, but a command line script or something to facilitate this job would be very helpful. Thank you.

Here are the steps to manually migrate a wiki from 10.5 to 10.6:
sudo serveradmin stop teams
sudo mv $GROUP_DIRECTORY /Library/Collaboration/Groups/
sudo chown -R 94:94 /Library/Collaboration/Groups/$GROUP_DIRECTORY
sudo rm /Library/Collaboration/dataVersion.plist
sudo rm /Library/Collaboration/globalIndex.db
sudo rm /Library/Application Support/Apple/WikiServer/directoryIndex.db
sudo serveradmin start teams
You will then need to navigate to the wiki as an administrator and set the access permissions in the wiki's settings screen. There you can restrict access by directory users and/or groups (if you need that level of granularity).

Repost: Migrating Wikis from 10.5.8 to 10.6.4

This topic was originally posted here: http://discussions.apple.com/message.jspa?messageID=10479747 It is marked as "solved" so no new posts permitted- but I'm having further issues not covered in that post so I'm reposting.
I too am migrating wiki data from 10.5 to 10.6. I followed the instructions posted by skip:
sudo serveradmin stop teams
sudo mv $GROUP_DIRECTORY /Library/Collaboration/Groups/
sudo chown -R 94:94 /Library/Collaboration/Groups/$GROUP_DIRECTORY
sudo rm /Library/Collaboration/dataVersion.plist
sudo rm /Library/Collaboration/globalIndex.db
sudo rm /Library/Application Support/Apple/WikiServer/directoryIndex.db
sudo serveradmin start teams
But now when trying to navigate to the "groups" area from the home page, or directly to any group directory via a web browser, I get a page with the spinning throbber graphic surrounded by a square with the title "Server Starting..." This icon refreshes every few seconds, but never goes away.
I assumed perhaps the OS was taking some time to rebuild the DB, so I waited a day and tried to navigate to the groups listing again. Same results.
I've now restored everything back to defaults. I can create new wikis, but can't seem to figure out a way to import data from our wiki pages from 10.5. There is a lot of data here that I'd hate to lose.
I have an Enterprise Support Agreement, but the techs there say that this issue is not covered.
Thoughts anyone?

It is really a mess. When this happens, we start over and try again. Either there are issues with file copies that don't work right in the system (pick your method, rsync, finder, yadda yadda) or the wiki system is a wee bit on the hobbyware side of things.
I have moved the wiki several times and this is what I end up doing:
• on both servers, stop the wiki server via sudo serveradmin stop teams
• copy the entire contents of the collaboration folder to the new server
• on the new server trash file:///Library/Collaboration/globalIndex.db
• on the new server trash file:///Library/Collaboration/dataVersion.plist
• on the new server trash file:///Library/Application%20Support/Apple/WikiServer/sessions.db
• on the new server trash file:///Library/Application%20Support/Apple/WikiServer/directoryIndex.db
• on the new server start the wiki server sudo serveradmin start teams

What do I need to migrate files from old eMac to new iMac?

I just purchased a new iMac and need to transfer information from my old eMac to the new one. I have not even taken the iMac out of the box, just read over the booklet.
What do I need to have to be prepared to migrate information from the start up application? USB cable? Firewire cable? I just want to be prepared so I can get it done at one setting. There isn't a lot of room on the desk for 2 Mac's for an extended period of time.

When you boot the new Mac, choose Migration Assistant to transfer all your data.

HT5082 Restoring wiki from TM backup

I don't have a bootable version of my source server, only a time machine backup. Will the first method —Migrating wiki data from Mac OS X Server v10.6 to Lion Server— work to move from my source TM to OS X Server v10.6?

Does http://support.apple.com/kb/HT5082 help at all? You would have to restore your TM backup to a separate disk, use that to startup, dump the wiki and postgres data to disk, reboot using your new server disk and follow the instructions to copy all wiki data to the new server.
Cheers
Gerry

Migration Assistant from a backup disk...

Is it possible upon first booting (or subsequently) to import the user account from a FireWire disk? I mean, it is so easy to import from another Mac with Migration Assistant but is there no similar way to import from a backup disk?
I'v done it the hard way by dragging and dropping the files but it seems like the permissions are always messed up and need time-consuming repair. It is also very difficult getting the preferences to be accepted while the application is already running.
Hoping there is an easy way, because I prefer to wipe the hard disk and install freshly.

no, MA will not understand that. then you'll have to migrate things by hand. check out this [link|http://discussions.apple.com/message.jspa?messageID=6185507] for a list of things to move.

Migrate clients from Exchange 2013 to a different Exchange 2013

Hi,
We are planning to migrate an Exchange 2013 instance to a centralized one. The question is how to deal with the Outlook OST mail files left over from the old instance and were wondering what best practices in this regard there may be.
Thanks in advance for any advice you can provide.

Hi,
Do you mean you want to migrate mailbox from one Exchange server to another Exchange server? If it is, we can directly move the whole mailbox to another mailbox server instead of Exporting/Importing a mailbox to PST file.
If you want to migrate a large number of user mailboxes, we can
specify a CSV file when you use the Exchange admin center (EAC) or the New-MigrationBatch cmdlet in the Exchange Management Shell to create a migration batch.
Here are some detailed information about mailbox moves in Exchange 2013:
http://technet.microsoft.com/en-us/library/dn170437(v=exchg.150).aspx
Move Mailbox in Exchange Server 2013
http://msexchangeteam.in/move-mailbox-in-exchange-server-2013/
Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please
make sure that you completely understand the risk before retrieving any suggestions from the above link.
Thanks,
Winnie Liang
TechNet Community Support

Why are the files I migrated over from a backup hard drive locked and inaccessible on my new used Mac Book pro? I used the migration assistant. Running Snow Leopard on a core duo.

My laptop got pinched and I bought a used Mac Book Pro, put a larger hard drive in it and performed a clean install of Snow Leopard on the new drive, after which I used the Migration Assistant to bring over my applications, settings, documents, etc., from my backup hard drive. This hard drivekis not a Ti e Machine drive, it's one I use to clone my computer to regularly with Carbon Copy Cloner. When the migration was complete all my documents, the desktop,and other folders are locked and won't allow me to access them. What to do? Thanks for the help.

Graham Giles wrote:
Have you seen this type of problem before? I think it could be a serious issue for anyone in a similar position.
No; but then, I've not had occasion to use TDM. I've been using firerwire drives for over 10 years, both FW400 and FW800, with no issues except a bit of instability using a B&W G3 machine.
TDM should be safe. Using cautious, manual copying of files from the Target machine to the Host machine should not result in unexpected loss of files or damage to the Target drive's directories. It should behave exactly the same as if it were an external (to the Host) firewire drive.
• I don't suppose there is anything I can do to 'put back' lost items from a separate Time Machine drive which has an up to date backup on it.
There is probably a way to do that - seems to me that's one of the reasons for a Time Machine volume.
On the other hand, if the Time Machine volume is rigidly linked to the now-absent OS on the original drive, there may be no way to effectively access the files in the TM archive.
I know that using a cloned drive would work well in this instance.
I have no experience with Time Machine, so perhaps someone who has will chime in with suggestions.
With the machine in TDM with the other machine, have you tried running Disk Utility to see if you can effect repairs to the drive?

Need help migrating users from dead 10.4.0 server to 10.5.8 server

Hello,
We have an ancient xserv (G4, SCSI drives I think) that was running 10.4.0 server, serving http, AFP and SMB, and doing the streaming for the college radio station to the internet(qt broadcaster was sending from another machine to this machine).
Apples recommended process for migration to a new machine is to first upgrade to 10.4.1 before exporting. However, the hard drive on this machine is as ancient as it is and the initial install process failed with an error, leaving the machine unbootable.
I used CCC to make a copy of the os to an identical drive, but this is not bootable either, nor can I sucessfully upgrade it to another version.
Is there some way to move all the config to the new server (MacPro running 10.5.8) without exporting from the old server, since this is not possible?
There are hundreds of users and user websites. I copied the websites over to the user folder and they are accessable but not by the original urls.
Thanks,
Joel

posted in wrong section sorry

Migrating wiki from one 10.6 server to another

Has anyone had any success and know the proper procedure for moving a wiki between two 10.6 servers? We're relocating it to different hardware. When I move the data store it does the "starting server" thing forever when you try to visit the web page. It doesn't look like python or wikid is doing much of anything after the first few seconds. When I delete the various .db sql lite databases as suggested for fixing other issues, they do get recreated but it still never fully starts.
The permissions are also correct on all the files so I know it is not that. Also, I did the migration using rsync3 and made sure it preserved proper permissions, extended attributes, etc.
I'm probably missing something but was wondering if anybody has done it. Thanks.
Message was edited by: Christopher Collins3

If you haven't figured the migration out already, you may want to check out this thread:
http://discussions.info.apple.com/thread.jspa?threadID=2205892
It looks like the path to take from everything I'm seeing, but if you've found a friendlier solution I'd be happy to give it a shot!

HT5139 OSX server failed, need to migrate wiki from TM backup to a different existing (configured) server

Similar Messages

Maybe you are looking for