locked
Putting SharePoint 2007 Server on another system RRS feed

  • Question

  • I have a production 2007 SharePoint Server running on a server. I am able to re-image the whole server into another system for testing and training purpose. Everything works fine on that system except SharePoint. Some reasons are because the IP address has changed and the URL has also changed. How do I access the SharePoint Server on the new system? I tried typing the IP number of the new system, but it doesn't work. I would appreciate very much if someone can tell me how I can bring the SharePoint server back to 'live' on the new system with a new IP number. I can't use the same URL name because the real one is in production and it is on the DNS.

    Thanks.

     

    Wednesday, May 19, 2010 4:28 PM

Answers

  • If the URL is different, you need to extend your web application to the new URL to update the AAM.

     

    Please read what follows from http://blogs.msdn.com/sharepoint/archive/2007/03/19/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-2-of-3.aspx

     

    Mistake #1: "I'm not deploying SharePoint in an unusual way, so I don't need to worry configuring Alternate Access Mappings."

    Probably the most common cause of AAM-related issues is administrators not realizing that they need to configure it in the first place. It's certainly understandable as this is a new requirement in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. The reality is that every SharePoint administrator needs to make sure that AAM is configured correctly, even if you're performing a simple deployment.

    For SharePoint to provide a robust and stable API that can work on multiple machines, even machines where the SharePoint web application service is not running, our resolution of URLs to SharePoint sites cannot rely on hosts files, DNS, or IIS bindings. Instead, once SharePoint receives a request it will only use AAM to perform that URL resolution. So while it is necessary to make sure your hosts files, DNS, and IIS bindings are properly configured so that a web request can reach the SharePoint server, it is also necessary to configure the URLs in AAM to match.

    …….

     

    Mistake #4: Updates made in AAM automatically update IIS bindings and vice versa.

    Actually, once a web application has been extended to a zone, SharePoint will not attempt to modify its IIS bindings. If you go into IIS and modify those bindings yourself, say by adding a host header binding, changing a port number, or adding an SSL port, SharePoint won't be aware of those changes and will not update the AAM URLs for you. Similarly, an update to the AAM URLs to add an SSL URL won't automatically update your IIS bindings to match.

    Instead, if you need to make a change in your IIS bindings, our recommendation is that you remove the SharePoint web application from that zone. Then you can re-extend the web application to that zone with your updated bindings.

     

    Please also read this for correct steps: http://technet.microsoft.com/en-us/library/cc262366(office.12).aspx

     

     

    Gu Yuming

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com

    • Proposed as answer by KSDN Thursday, May 20, 2010 9:09 AM
    • Marked as answer by GuYuming Monday, May 31, 2010 1:46 AM
    Thursday, May 20, 2010 7:45 AM

All replies

  • First of all, the URL doesn't have to change. You can use the same URL pointing to different IP. The only change you need to make is tweak the Hosts file in windows folder.

    On any client (I mean developer machine), go to C:\WINDOWS\system32\drivers\etc, open up the file call hosts. Change the IP in the hosts as following:

    # Copyright (c) 1993-1999 Microsoft Corp.
    #
    # This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
    #
    # This file contains the mappings of IP addresses to host names. Each
    # entry should be kept on an individual line. The IP address should
    # be placed in the first column followed by the corresponding host name.
    # The IP address and the host name should be separated by at least one
    # space.
    #
    # Additionally, comments (such as these) may be inserted on individual
    # lines or following the machine name denoted by a '#' symbol.
    #
    # For example:
    #
    #      102.54.94.97     rhino.acme.com          # source server
    #       38.25.63.10     x.acme.com              # x client host

    127.0.0.1       localhost
    100.100.101.1    sharepoint.yourcompany.com                         # PROD SERVER
    #100.100.101.2    sharepoint.yourcompany.com                       # DEV SERVER

    Change the IPs, URLs in the above text. Save it, close IE and reopen it. If you want to access Dev Server, remove the "#" sign for DEV SERVER in hosts file, put "#" before PROD SERVER. Save it, close IE and reopen.


    -Bin
    • Edited by Bin_ Thursday, May 20, 2010 2:03 PM
    Wednesday, May 19, 2010 5:03 PM
  • If the URL is different, you need to extend your web application to the new URL to update the AAM.

     

    Please read what follows from http://blogs.msdn.com/sharepoint/archive/2007/03/19/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-2-of-3.aspx

     

    Mistake #1: "I'm not deploying SharePoint in an unusual way, so I don't need to worry configuring Alternate Access Mappings."

    Probably the most common cause of AAM-related issues is administrators not realizing that they need to configure it in the first place. It's certainly understandable as this is a new requirement in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. The reality is that every SharePoint administrator needs to make sure that AAM is configured correctly, even if you're performing a simple deployment.

    For SharePoint to provide a robust and stable API that can work on multiple machines, even machines where the SharePoint web application service is not running, our resolution of URLs to SharePoint sites cannot rely on hosts files, DNS, or IIS bindings. Instead, once SharePoint receives a request it will only use AAM to perform that URL resolution. So while it is necessary to make sure your hosts files, DNS, and IIS bindings are properly configured so that a web request can reach the SharePoint server, it is also necessary to configure the URLs in AAM to match.

    …….

     

    Mistake #4: Updates made in AAM automatically update IIS bindings and vice versa.

    Actually, once a web application has been extended to a zone, SharePoint will not attempt to modify its IIS bindings. If you go into IIS and modify those bindings yourself, say by adding a host header binding, changing a port number, or adding an SSL port, SharePoint won't be aware of those changes and will not update the AAM URLs for you. Similarly, an update to the AAM URLs to add an SSL URL won't automatically update your IIS bindings to match.

    Instead, if you need to make a change in your IIS bindings, our recommendation is that you remove the SharePoint web application from that zone. Then you can re-extend the web application to that zone with your updated bindings.

     

    Please also read this for correct steps: http://technet.microsoft.com/en-us/library/cc262366(office.12).aspx

     

     

    Gu Yuming

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com

    • Proposed as answer by KSDN Thursday, May 20, 2010 9:09 AM
    • Marked as answer by GuYuming Monday, May 31, 2010 1:46 AM
    Thursday, May 20, 2010 7:45 AM
  • I did that. When I enter http://100.100.101.1, I get Internet Explorer cannot display the webpage error.

    Do I have to plug int the cat 5 cable from the wall? 

    Monday, September 13, 2010 7:45 PM