When creating a new web application in SharePoint, you choose the physical location of where the IIS website will be created. Once the application is born, however, there is no longer an option to change this path in Central Administration. You can very easily change it in IIS (by going to your website’s Properties -> Home Directory -> Local Path), but once this is done, you will start running into trouble, as solution deployments will point to the web.config file at the old location.
Three quick steps need taken to successfully move the web application:
- Copy the current directory’s contents into your new directory
- Make the change to the website’s local path in IIS (as described above)
- Update the SharePoint web application to point to the new path
Note: If you have multiple servers in your farm, steps 1 and 2 will need made on each web server, but step 3 will only need done once.
The third step can be done without having to extend the site. Here are a couple options.
Option 1: C# Console Application (Reference Microsoft.SharePoint.dll)
using System; using System.IO; using Microsoft.SharePoint; using Microsoft.SharePoint.Administration; namespace IisPath { class Program { static void Main(string[] args) { try { //Open the site your web application hosts using (SPSite site = new SPSite("http://yoursite.com")) { //Grab a reference to the site's web application's IIS Settings //Change SPUrlZone if application is not in default zone SPIisSettings iisSettings = site.WebApplication.IisSettings[SPUrlZone.Default]; //Point to your new path iisSettings.Path = new System.IO.DirectoryInfo(@"D:\wss\VirtualDirectories\yoursite.com"); //Call the Update method of the web application site.WebApplication.Update(); } } catch (Exception ex) { Console.WriteLine(ex.Message); Console.ReadLine(); } } } }
Option 2: PowerShell Script
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") #Point to the site your web application hosts to grab a reference to the web application $SPSite = new-object Microsoft.SharePoint.SPSite("http://yoursite.com") $WebApp = $SPSite.WebApplication #Change SPUrlZone if not in default zone $IISSettings = $WebApp.IisSettings[[Microsoft.SharePoint.Administration.SPUrlZone]::Default] #Point to your new directory $IISSettings.Path = "D:\wss\VirtualDirectories\yoursite.com" #Update Web Application $WebApp.Update() $SPSite.Dispose()
I hope this has been helpful, and as always, thank you for reading.
Cheers.



Thanks for this helpful overview! I would like to add a comment and a question:
1) Step 2 can be a bit more complex than simply changing the local path. (See Microsoft TechNet http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a59a2665-9078-43ef-8b5a-5bf9bcacc95e.mspx?mfr=true)
2) Since I am an administrator, not a developer, is there a way to accomplish step 3 without writing code? For example, do you if there are stsadm commands that can be used to do this?
Thank you very much for this post, you have saved my day. I have created simple console application that is based on your code at http://codearound.blogspot.com/2010/01/sharepoint-how-to-move-virtual.html.
Fantastic! Step 3 is what we were missing and it resolved a mysterious issue that brought deployment to a screeching halt.
Dude, you rock!
[...] to Change the IIS Path for a SharePoint Web Application http://www.mattjimison.com/blog/2009/02/26/how-to-change-the-iis-path-for-a-sharepoint-web-applicati... Posted in SharePoint | Leave a Comment »Tags: [...]
Great, saved my day
Thanks a lot, you saved my day, too.
I simplified a bit the Powershell code (applicable to an app, too, of course) in order to remove the need for the SPSite. Here it is:
[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)
function Change-Path([string] $WebAppUrl, [string] $NewPath) {
if ([String]::IsNullOrEmpty($WebAppUrl) -or [String]::IsNullOrEmpty($NewPath)) {
write-host “Usage: Change-Path Web_path_URL New_Physical_Path”
return
}
$di = new-object System.IO.DirectoryInfo $NewPath
if ($di.Exists -eq $false) {
write-host “Path “, $NewPath, ” does not exist”
return
}
Write-Host “Moving “, $WebAppUrl, ” to “, $NewPath
$WebApp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup($WebAppUrl)
$IISSettings = $WebApp.IisSettings[[Microsoft.SharePoint.Administration.SPUrlZone]::Default]
$IISSettings.Path = $NewPath
$WebApp.Update()
}
Thanks for posting this! Step 3 resolved an issue in my very large farm. Thanks again.
Hi,
Thanks a lot for the detailed information.
We are also in the need of changing the root directory of the web application on our production server(large farm). Is it safe to go ahead with your approach? Your suggestions are highly appreciated.
Thanks
Shwetha
Shwetha,
Any advice you take from this blog is done at your own risk, but if you make the update in your production environment, I would strongly urge you to plan accordingly in terms of first pre-testing in a UAT environment, taking proper disaster / recovery steps, as well as scheduling a good amount of time to make the update. Make sure that the appropriate changes are made on all of your WFE’s – i.e. copying the current directory of files over to your new location as well as changing the path in IIS. I would take the other comments on this post into consideration, in terms of looking at first-hand experience of users who have performed the operation. I also have not personally done this in SharePoint 2010, so keep that in mind if that is your case. If you do decide to go forward with this method, good luck to you, and be sure to report back here with how it went!
In some cases, calling $spweb.provisionglobally() will cause each WFE to make the updates in IIS. If Path is one of those settings that doesn’t get updated w/ just ProvisionGlobally(), you can call $spweb.UnprovisionGlobally($true) followed by $spweb.ProvisionGlobally() to recreate the sites in IIS via SharePoint.
This alleviates the need to do the file copy and IIS changes completely.
Note: Any customization done in IIS Manager or manually to files would be lost.
This is great – thanks! I did have to go in and manually change my permissions on the new folder giving everyone read access, but other than that, worked like a charm.