Server 4.1 Profile Manager Migration Failed

Question

Level 1

54 points

Server 4.1 Profile Manager Migration Failed

It looks like in upgrading to the recently released 4.1 went okay, except my Profile Manger migration failed. I tried to re-run migration using the KB here: OS X Server: Resolving issues with Profile Manager - Apple Support however this doesn't exist at all: sudo /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/CommonE xtras/80-devicemgrcommon.sh

I see this in my logs:

[17213] [2015/04/09 08:20:31.489] -[SULogFileCollection setGlobalLogLevelPrefix:]: YES

0:: [17213] [2015/04/09 08:20:31.491]

############################################################################### ####

migration_tool-886.204 (PID:17213, OS:14D131, SERVER:14S1092, ARCH:x86_64) starting

LA: migration_tool

############################################################################### ####

0:: [17213] [2015/04/09 08:20:31.556] Waiting for postgres to startup....

0:: [17213] [2015/04/09 08:20:31.961] +[PGConnection reloadPreferences]: DBDebug = NO, DBLogNotices = NO, DBLogSQL = NO, DBMonitor = NO

0:: [17213] [2015/04/09 08:20:32.921] +[PGConnection reloadPreferences]: DBDebug = NO, DBLogNotices = NO, DBLogSQL = NO, DBMonitor = NO

0:: [17213] [2015/04/09 08:20:34.223] Dropping views...

0:: [17213] [2015/04/09 08:20:34.926] Dropping trigger functions...

0:: [17213] [2015/04/09 08:20:35.636] Dropping remaining non-dependent functions...

0:: [17213] [2015/04/09 08:20:37.251] MIGRATE_00885.001 completed successfully

0:: [17213] [2015/04/09 08:20:37.356] MIGRATE_00885.003 completed successfully

0:: [17213] [2015/04/09 08:20:37.749] EXCEPTION: Postgres <-[PGConnection executeCSQL:] (/SourceCache/RemoteDeviceManagement/RemoteDeviceManagement-886.204/Compiled/Fr amework-Models/Postgres/PGConnection.m:339): "Postgres error 2BP01 (ERROR: cannot drop function dm_current_timestamp() because other objects depend on it

DETAIL: default for table devices column last_update_info_time depends on function dm_current_timestamp()

HINT: Use DROP ... CASCADE to drop the dependent objects too.

)">

USERINFO: {

SQLSTATE = 2BP01;

errorMessage = "ERROR: cannot drop function dm_current_timestamp() because other objects depend on it\\nDETAIL: default for table devices column last_update_info_time depends on function dm_current_timestamp()\\nHINT: Use DROP ... CASCADE to drop the dependent objects too.\\n";

}

0:: [17213] [2015/04/09 08:20:37.749] SQL Module failed at statement:

------------------------------------------------------------------------------- -------

DROP FUNCTION dm_current_timestamp();

------------------------------------------------------------------------------- -------

-[PGConnection executeCSQL:] (/SourceCache/RemoteDeviceManagement/RemoteDeviceManagement-886.204/Compiled/Fr amework-Models/Postgres/PGConnection.m:339): "Postgres error 2BP01 (ERROR: cannot drop function dm_current_timestamp() because other objects depend on it

DETAIL: default for table devices column last_update_info_time depends on function dm_current_timestamp()

HINT: Use DROP ... CASCADE to drop the dependent objects too.

)"

0:: [17213] [2015/04/09 08:20:37.749] Caught unhandled exception -[PGConnection executeCSQL:] (/SourceCache/RemoteDeviceManagement/RemoteDeviceManagement-886.204/Compiled/Fr amework-Models/Postgres/PGConnection.m:339): "Postgres error 2BP01 (ERROR: cannot drop function dm_current_timestamp() because other objects depend on it

DETAIL: default for table devices column last_update_info_time depends on function dm_current_timestamp()

HINT: Use DROP ... CASCADE to drop the dependent objects too.

)"

0:: [17213] [2015/04/09 08:20:37.749] Migration failed at MIGRATE_00885.004 (final step is MIGRATE_00886.204)

0:: [17213] [2015/04/09 08:20:38.018] +[PGConnection reloadPreferences]: DBDebug = NO, DBLogNotices = NO, DBLogSQL = NO, DBMonitor = NO

0:: [17213] [2015/04/09 08:20:38.023] ShutdownMigrator: 2015-04-09 12:20:38 +0000

0:: [17213] [2015/04/09 08:20:38.023] BYE

Any ideas anyone?

Posted on Apr 9, 2015 4:05 PM

Reply

Answer 1

Best reply

mscott_mdm

Level 2

459 points

Apr 9, 2015 5:32 PM in response to Steven Major

Hi Steven,

Did anyone ever help you in the past with SQL commands for Profile Manager? It's strange, because the normal default for this column should be 'epoch', not dm_current_timestamp() and I'm wondering how it got changed.

In any case, I think this will fix this particular problem:

sudo psql -U _devicemgr -d devicemgr_v2m0 -h /Library/Server/ProfileManager/Config/var/PostgreSQL -c "ALTER TABLE mdm_targets ALTER COLUMN last_update_info_time SET DEFAULT 'epoch'"

Then run the setup script (which got moved in Server 4):

sudo /Applications/Server.app/Contents/ServerRoot/usr/libexec/deviceManagerCommon.sh

Reply

Answer 2

Steven Major Author

Level 1

54 points

Apr 9, 2015 6:40 PM in response to mscott_mdm

Hi mscott_mdm,

That seems to have fixed it. Thank you very much! I'll check it out a little more carefully tomorrow.

That's quite a loaded question, and I wish I could accurately answer it! Besides this Server instance, which is my family server, I also run two Servers at work with about 1200 clients split between them, all Profile Manager'ed. So, I'm been in here for years with problems/questions on all the systems. I recognize your name enough to know you've helped me a bunch of times through your posts even if I didn't directly ask the question (thanks AGAIN, btw).

I don't typically go spelunking in PM's psql, unless it is to delete a printer from the database since, to my knowledge, Apple still hasn't fixed that little bug from version 1.0.

Anyway, I'm fairly sure I didn't change anything date related on this family server, but it has been upgraded/migrated through version 1.0 of the Server.app so who knows what it has gone through OR maybe what I had done to fix some other issue long ago and forgot about.

But, good to have it working again.

Grateful,

-Steve

Reply

Answer 3

Apr 21, 2015 12:45 PM in response to mscott_mdm

Looks like this was due to a change I recommended people make to fix an earlier problem. See any of these threads:

https://discussions.apple.com/thread/6010430

https://discussions.apple.com/thread/6008083

https://discussions.apple.com/thread/6011762

https://discussions.apple.com/thread/6016958

If you applied the "ALTER TABLE" workaround mentioned in any of these threads, you will encounter the problem in this thread when upgrading to Server 4.1.

Reply