locked
Upgrade of existing Sharepoint 2007 instance RRS feed

  • Question

  • Hi,

    We have a legacy Sharepoint 2007 instance running bespoke .NET 2 code for web parts, site collection creation etc etc.

    It is currently residing across 3 servers, one APP server and 2 web servers which are load-balanced.

    The APP server OS is Windows Server 2008 Standard, as are the 2 web servers.

    The back-end SQL instance it is connected to is SQL Server 2008 clustered instance.

    We have a DR project here that means we have migrated most databases off the 2008 instance and onto 2008 R2.

    However we have heard that IT IS NOT POSSIBLE to migrate the Sharepoint databases off onto another instance of SQL Server due to an issue with the Sharepoint Config database.

    We anticipated migrating all databases (by way of replication) onto the new 2008 R2 instance and then changing the existing DNS references to point to the new instance, thus not having to change connection strings all over the place.

    Apparently this will not work which is posing a nightmare scenario - either having to keep the old cluster in place, purely for this legacy application/Sharepoint OR trying to recreate the Sharepoint Farm in it's entirety (the problem with this is that all Sharepoint knowledge has left the company and the original creators/setup people have long gone).

    Does anyone have any suggestions as to what any other options may be ? I can provide more detail as to the current/future setups if required, but in essence I think the problem is migrating the Sharepoint DB's from SQL Server 2008 > SQL Server 2008 R2.

    Thanks in advance.

    Monday, February 17, 2014 4:52 PM

All replies

  • Hi,

    This is one reason  why you should always use SQL Aliases when configuring SharePoint 

    Assumption: All DBs on the Old server have been migrated to the New server, along with usernames and role assignments for each Db

    Stop the SharePoint Services on all SharePoint servers, you can use Server Manager

    From the command line

    1. Enter CLICONFG
    2. Highlight TCPIP, Click Enable
    3. Click on the Alias Tab, and Click Add
    4. Click the TCPIP Radio Button
    5. Enter the (Old Database Server Name) in the Server Alias Box
    6. Enter the (Cloned Database Server Name) Server Name in the Server Name Box
    7. Uncheck, Dynamically Assign
    8. Enter Port 1433, and Click OK. Make sure on your new SQL Server that you don't have an inbound rule blocking Port 1433.
    9. On the SharePoint Servers re-start the SharePoint Services
    10. Run IISReset

    To test stop the SQL Service on the Old Server and login to SharePoint

    Cheers,


    -Ivan

    Monday, February 17, 2014 6:38 PM
  • Thanks, but what about the rest of it, all the bad stories I've been told (from actual professional Sharepoint implementers) whereby you can't perform this kind of SQL migration due to the Configuration DB and the fact that Sharepoint hard-codes some kind of values within it's DB tables which point to that machine ?

    Or are you seriously saying that that's "all" I'd have to do ?

    Thanks.

    Monday, February 17, 2014 7:22 PM
  • We were going to use a logshipping/mirroring migration method but here is the issue that I've heard causes a problem :

    Carrying out a straight forward Logshipping/Mirroring migration method is not recommended due to a number of databases that contain Machine Specific records. 

    These records only contain information about the server/cluster that it is hosted on.  Logshipping and mirroring these databases is practically copying all databases to a new server rendering these machine specific records invalid. 

    This applies only to the Configuration, Central Admin and search based Databases but not the Content databases.

    Tuesday, February 18, 2014 5:55 PM
  • I've performed these types of migrations countless times, it works as ivan has outlined.

    MCITP-EA | "Never test how deep the water is with both feet"


    • Edited by ThatGuyRyan Wednesday, February 19, 2014 3:52 AM
    Wednesday, February 19, 2014 3:51 AM
  • Even if the IP addresses and FQDN's of the servers it's being migrated to are changing (although we want to try and change them back as obviously i'll have to change loads of connection strings if we leave them changed) ?

    Here's the issue in more detail, really would appreciate someone to have a read, this has bad ramifications for us and we need to get it right :

    Current set up: 
    Sharepoint 2007 server on Windows 2003 Server OS based on a SQL Server 2008 back-end DB cluster

    Requirement: 
    Move the back-end database onto a Windows 2008 R2 OS based on SQL Server 2008 R2 (clustered)

    The issue is as follows:

    Initially, A pure log shipping method was planned.  

    To try and minimize the amount of downtime, the new SQL instance was installed as XXX10VSS20 onto the XXX10VSS22 Cluster Group.  

    This was given a full named instance as XXX10VSS22/XXX10VSS20.  

    In this case, XXX10VSS22 would be the Host name and is resolvable to an IP address. 

    Log shipping was to be setup on all the databases on the old instance XXX10VSS20/XXX10VSS20 to XXX10VSS22/XXX10VSS20.  

    For the actual cutover, the plan was to block access to XXX10VSS20/XXX10VSS20, run a final Transactional Log Backup, ship all the logs over to XXX10VSS22/XXX10VSS20 and replay all logs.  

    Once done, Update the DNS record by either adding a new Host or CName record. This would then result in lookups to XXX10VSS20 resolving to the IP address of XXX10VSS22 and with the instance name already the same, all database connections will reach the correct instance. 

    Assume the following – 
    (old) XXX10VSS20 (cluster name) – resolves to 90.90.90.90 with SQL Instance XXX10VSS20 Installed.
    (new) XXX10VSS22 (cluster name) – resolves to 90.90.90.100 with SQL Instance XXX10VSS20 Installed.

    So the full IP/host name/named instance combination would be – 
    XXX10VSS20/XXX10VSS20 or 90.90.90.90/XXX10VSS20
    XXX10VSS22/XXX10VSS20 or 90.90.90.100/XXX10VSS20

    Update the DNS records for XXX10VSS20 to resolve to XXX10VSS22

    We now have XXX10VSS20/XXX10VSS20 = 90.90.90.100/XXX10VSS20

    This was assuming that the hostname XXX10VSS20 is used in connection strings as opposed to the IP address and no local host files have been used.

    However on further investigation, carrying out a straight forward Logshipping/Mirroring migration method is not recommended due to a number of databases that contain Machine Specific records.  These records only contain information about the server/cluster that it is hosted on.  Logshipping and mirroring these databases is practically copying all databases to a new server rendering these machine specific records invalid.  This applies only to the Configuration, Central Admin and search based Databases but not the Content databases. 

    The correct way in which to achieve this is to effectively create a DR farm and failover to DR.  Once successful, Production can be removed and DR will now become Production.  This implies that a New Cluster, Frontend and Application Servers be available to take over the existing Production Farm.

    The following article, although does not detail migration steps, shows how a normal DR environment is setup and works and the basis that should be used in the description above. 
    http://technet.microsoft.com/en-us/library/dd890507(v=office.12).aspx


    Wednesday, February 19, 2014 12:20 PM