Kommentarer till Episerver Migration 4.62 to CMS5 r2 on SQL Server 2008 http://www.from-rizo.se/2009/02/06/episerver-migration-462-to-cms5-r2-on-sql-server-2008/ A blog that brings up subjects regarding developing web applications, Android applications and gaming overall Sat, 04 Feb 2012 18:22:13 +0000 hourly 1 http://wordpress.org/?v=3.2.1 Av: Rizo http://www.from-rizo.se/2009/02/06/episerver-migration-462-to-cms5-r2-on-sql-server-2008/comment-page-1/#comment-34 Rizo Wed, 11 Feb 2009 07:59:00 +0000 http://www.from-rizo.se/?p=199#comment-34 thats quite a trip mate! :) crazy that it was using the NETBIOS name. Let me know how the rest of the migration works out for you. thats quite a trip mate! :) crazy that it was using the NETBIOS name. Let me know how the rest of the migration works out for you.

]]> Av: Ed Shape http://www.from-rizo.se/2009/02/06/episerver-migration-462-to-cms5-r2-on-sql-server-2008/comment-page-1/#comment-31 Ed Shape Tue, 10 Feb 2009 21:25:17 +0000 http://www.from-rizo.se/?p=199#comment-31 I'm on a migration process right now and I got some similar problems as you describe. The migration was from version 4.60 to 5.2. I got problems through all steps. First off, upgrading from 4.60 to 4.62B which on every attempt hanged sql server 2005 causing an automatic reboot. Finally,I fixed this by running all sql conversion scripts manuallt on my local dev machine and then restoring it back on the server (where my migration sites resided). Everything fine.. till next breath. Migration tool running fine but suddenly stops, times out into a nice latch 4 sql exception and sql server 2005 stops responding with locked up databases. All this causing another fine deep dive into log analysis and google fishing. After some headache trying to find a solution I backed up the ******* database, moving it to dev machine again. My strategy now was to run the migration tool on the server but converting the database remote on my dev machine. I ran the tool and it looked really good this time. Just some steps further .. till .. MSDTC exception running wild. Well, after some time resolving the issue using DTSPing after enabling MSDTC transaction on both machines I was still without luck. And then it hit me. My sql connection string was set up with my dev machine IP adress as source. But after some (many) thoughts I realized that instead of using this IP as endpoint, the MSDTC handling was looking up my dev machine NETBIOS name. Pinging this name from my server showed that dns wasnt synced correctly. A fine ipconfig /flushdns took place .. and OH YEAH! Migration Tool runs across all steps and FINALLY: Migration Complete. Well, nice experience and now there's some bad ass code migration in progress ;) Happy migration y'all! (Ps. Dont know yet why the server always hanged during these steps because of some latch-4 exceptions) I’m on a migration process right now and I got some similar problems as you describe. The migration was from version 4.60 to 5.2. I got problems through all steps. First off, upgrading from 4.60 to 4.62B which on every attempt hanged sql server 2005 causing an automatic reboot. Finally,I fixed this by running all sql conversion scripts manuallt on my local dev machine and then restoring it back on the server (where my migration sites resided).

Everything fine.. till next breath. Migration tool running fine but suddenly stops, times out into a nice latch 4 sql exception and sql server 2005 stops responding with locked up databases. All this causing another fine deep dive into log analysis and google fishing. After some headache trying to find a solution I backed up the ******* database, moving it to dev machine again.

My strategy now was to run the migration tool on the server but converting the database remote on my dev machine. I ran the tool and it looked really good this time. Just some steps further .. till .. MSDTC exception running wild. Well, after some time resolving the issue using DTSPing after enabling MSDTC transaction on both machines I was still without luck. And then it hit me. My sql connection string was set up with my dev machine IP adress as source. But after some (many) thoughts I realized that instead of using this IP as endpoint, the MSDTC handling was looking up my dev machine NETBIOS name. Pinging this name from my server showed that dns wasnt synced correctly. A fine ipconfig /flushdns took place .. and OH YEAH! Migration Tool runs across all steps and FINALLY: Migration Complete.

Well, nice experience and now there’s some bad ass code migration in progress ;)

Happy migration y’all!

(Ps. Dont know yet why the server always hanged during these steps because of some latch-4 exceptions)

]]>