Freigeben über

Pros/Cons of 3 Options to Change URL and Bindings for a Web Application in SharePoint Server

  • Artikel

In this post I discuss pros and cons of 3 options to change a URL for a SharePoint Server web application.  I do not recommend using Option 1, and explain why below. Whether to use Option 2 or 3 will depend upon your particular scenario and requirements, and there’s pros and cons for each option.  Note: How to add additional URLs and IIS bindings to a web application is covered in a separate blog post, and can be accomplished by extending the web application into an unused zone.

Example Scenario: You want to revise the default URL (https://servername:5555) for an existing SharePoint 2010 web application to be a more user-friendly URL (https://inside.contoso.com). Then users will solely access the web application using the new user-friendly URL.

Option 1: Edit Bindings of IIS and Change the Alternate Access Mapping [NOT RECOMMENDED]

1.1 Go to Central Administrator, System Settings, Farm Management, Configure alternate access mappings, Alternate Access Mapping Collection, Change Alternate Access Mapping Collection, Select the collection corresponding to the Web Application you wish to change.

1.2 Click Edit Public URLs, overtype the URL you wish to change, and click Save to save your AAM change.  SharePoint does not automatically change any bindings in IIS.

1.3 Using IIS Manager on each WFE server, manually change the bindings for the corresponding web site to match URL change.  Good idea to do an IISRESET /NOFORCE after changing IIS bindings.

1.4 Open a SharePoint Management Shell and execute PowerShell to update the display Name of the SharePoint web application to something meaningful.  For example,

 $rwa=Get-SPWebApplication | where {$_.Name -match "Your Old Web Application Name"}
 $rwa.Name
 $rwa.Name="Your New Web Application Name"
 $rwa.Update()
 Get-SPWebApplication | where {$_.Name -match "Your New Web Application Name"}

Pros:

  • Avoids having to extend web application into another AAM zone (which would create an additional backing web site in IIS)
  • Deployed custom solutions, including web.config customizations, are generally unaffected by this approach.

Cons:

  • When you change the URL (Host Header and/or Port bindings) of a SharePoint web application by updating the Alternate Access Mapping and manually update the bindings in IIS, the SPWebApplication object which is stored in the objects table in the configuration database is never updated so it continues to maintain bindings knowledge of the original URL and not the new one.   When you start the Microsoft SharePoint Foundation Web Application service in Central Admin (or via PowerShell), the information from the associated SPWebApplication object in the configuration database is used when instantiating IIS Sites and original URL shows up.  How to avoid this issue?  The SharePoint PowerShell cmdlets do not provide a direct way to update web app bindings stored in the Config DB.  However, you could use PowerShell in combination with client site object model code to update the web app bindings in the config db to changed values.
  • Changing the display Name property of the SharePoint web application via PowerShell does not correspondingly change the Alternate Access Mapping Collection name, which can be confusing.  Doesn’t seem to be a PowerShell cmdlet to directly change this AAM collection name.  Perhaps it can also be changed using PowerShell and client side object model code, but I haven’t explored this possibility.

Option 2: Un-extend and re-extend the Web Application In SharePoint

2.1 Go to Central Administrator, Application Management, Select the Web Application you wish to change and click the arrow under Delete and choose Remove SharePoint from IIS Web Site.

2.2 Next, select the associated IIS Web site for which want to update the URL.  For Delete IIS web sites, select No and click OK.  Note: Content databases and IIS web sites are preserved.

2.3 Go to Central Administrator, Application Management, Select the same Web Application and choose Extend button on the ribbon.

2.4 Choose Use an existing IIS Site and choose the original site from Step 2.2 above. Specify the new IIS Web Site bindings, Host Header and/or Port, and any other settings that should match.  SharePoint will automatically update the bindings in corresponding web site in IIS.

Pros:

  • Because you are re-using existing web site in IIS when you re-extend web app, this approach avoids extending web app and creating an additional backing web site in IIS.
  • SharePoint automatically updates the corresponding web site bindings in IIS when using this technique.
  • Whenever you create/extend a web application, SharePoint stamps the IIS Web Site bindings on the spwebapplication object which is stored in the objects table in the configuration database.  

Cons:

  • Custom solutions. 
    • If you perform these steps on a web app with only one zone all the solutions deployed to the web app will be dissociated. Re-deploying them may cause issues because features might already be activated.  Test!
    • If the web.config for a web application has been manually customized outside of SharePoint, be aware that Extending a web application creates a new default web.config file and will lose your customizations.

Option 3: Delete and re-create the Web Application in SharePoint

3.1 Go to Central Administration, Application Management, Select the Web Application you wish to change and click the arrow under Delete and choose Delete Web Application. Selection delete options to keep the content databases but delete the IIS web site.

3.2 In Central Administration, Application Management, click New to create a new application.

3.3 Specify a new IIS Web Site and new binding information, Host Header and/or Port.  For Database Name, specify the existing content database name retained in step 3.1. Verify that the Public URL field is correct.  Specify any other settings as appropriate.  Click Save to create the new web app and IIS web site, reusing existing content database.

Pros:

  • Because you are deleting and recreating web site in IIS, this approach avoids extending web app and creating an additional backing web site in IIS.
  • SharePoint automatically updates the corresponding web site bindings in IIS when using this technique.
  • Whenever you create/extend a web application, SharePoint stamps the IIS Web Site bindings on the spwebapplication object which is stored in the objects table in the configuration database.  

Cons:

  • Suitable only if web application is not currently extended and URL exists only in Default zone.
  • Custom solutions. 
    • If you perform these steps on a web app with only one zone all the solutions deployed to the web app will be dissociated. Re-deploying them may cause issues because features might already be activated.  Test!
    • If the web.config for a web application has been manually customized outside of SharePoint, be aware that recreating a web application creates a new default web.config file and will lose your customizations.

ADDITIONAL REFERENCES

Update a web application URL and IIS bindings for SharePoint 2013
https://technet.microsoft.com/en-us/library/cc262366.aspx

How to properly change the Host Header URL of a web application in SharePoint 2010
https://blogs.msdn.com/b/russmax/archive/2013/02/27/how-to-properly-change-the-host-header-url-of-a-web-application-in-sharepoint-2010.aspx