Office-docs-powershell: Move-SPSite: "An IIS reset is required for the site move to take effect."

[fowl2]

I just tested this on SharePoint 2013:

1. Open a site in a web browser- verify it is accessible.
2. Run Move-SPSite and wait for it to complete.
3. Open the site in a web browser again - verified it is still accessible.

Notice no iisreset. The site shows under its new content database in central administration.

Is this document saying that the site won't actually be moved until IIS is restarted? What if I have multiple servers?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 4d77b895-234c-9584-7806-2c39a7d607d0
• Version Independent ID: 3ce7d735-77bd-25e4-a961-ef9e3195ecaf
• Content: Move-SPSite (sharepoint-server)
• Content Source: sharepoint/sharepoint-ps/sharepoint-server/Move-SPSite.md
• Product: sharepoint-powershell
• GitHub Login: @techwriter40
• Microsoft Alias: kirks

[yogkumgit]

@officedocsbot assign @yogkumgit

[get-itips]

Hello @fowl2 How are you?
As many operations in SharePoint Server, as SharePoint relies heavily on iis, the iisreset is a required step after issuing a cmdlet of big impact like that. I see that in your scenario, it wasn't needed, but we can not be sure it won't be needed the next time you run it or in another environment, when issuing an iisreset, we can be sure web applications are fully recycled before receiving any requests, preventing any non desirable errors.
Thanks

[yogkumgit]

@get-itips Thank you very much for the contribution and sharing this explanation. @fowl2
Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.

[fowl2]

So if I understand correctly, an iisreset is 'sometimes' required, and it's been to decided not to document those conditions?

Also, could you detail the recommend procedure for multi-server farms - the most common deployment I would imagine. Should iisreset be executed on all front ends in the farm? All servers? Just those with the web application in the farm?

[get-itips]

So if I understand correctly, an iisreset is 'sometimes' required, and it's been to decided not to document those conditions?

Also, could you detail the recommend procedure for multi-server farms - the most common deployment I would imagine. Should iisreset be executed on all front ends in the farm? All servers? Just those with the web application in the farm?

Hello @fowl2 James how are you? Hope you are doing great.
I will answer your question now with my experience and also I invite the designated author of the article @Techwriter40 (Kirk) if he wants to add something or if he can get internal information from the product team.
In my experience, and based on this article, I always ran an iisreset on all servers in the farm, that way I could reduce the chance of any "cached pointer" to the old database and if any further error appeared I was sure it was not related to the Move operation (Because I did what the documentation said).
Let me understand you, are you running Move-SPSite as a common/frequent step in your environment?

[fowl2]

Hi, thanks for you quick responses, most appreciated.

It's not a common operation (so I'm relying on the documentation more than usual) but as iisreset is a fairly disruptive operation I'd like to try to avoid it.

[tseward]

@TroyStarr any insight as to why iisreset is a requirement after issuing Move-SPSite? That one has never made sense to me, either.

[TroyStarr]

Hi @tseward, I took a look at the spec for this feature (first checked in back in 2007). It said this needed to be done on all front-ends after the site move is finished to prevent failures when users browse to the newly moved sites. Presumably this would refresh stale site map caches on those front-ends. I don't know if any changes have happened since then to make this step unnecessary, though.

[get-itips]

Hi @tseward, I took a look at the spec for this feature (first checked in back in 2007). It said this needed to be done on all front-ends after the site move is finished to prevent failures when users browse to the newly moved sites. Presumably this would refresh stale site map caches on those front-ends. I don't know if any changes have happened since then to make this step unnecessary, though.

Thanks @TroyStarr for sharing that information. @tseward @TroyStarr Would you agree on updating the article stating that the iisreset is needed on all front-ends?

[TroyStarr]

I just finished chatting with some members of the team and they say that they've made changes over time to address the stale site map caching issues. So when they do a site move in SharePoint Online, they don't need to perform an iisreset on any servers.

It's likely that we no longer need the iisreset for SharePoint Server 2019, but it's unclear whether this would also apply to earlier versions of SharePoint Server. I'd be fine if we wanted to document that older versions of SharePoint Server should still run this command on all front-ends, but it's no longer needed for SharePoint Server 2019.

[get-itips]

I just finished chatting with some members of the team and they say that they've made changes over time to address the stale site map caching issues. So when they do a site move in SharePoint Online, they don't need to perform an iisreset on any servers.

It's likely that we no longer need the iisreset for SharePoint Server 2019, but it's unclear whether this would also apply to earlier versions of SharePoint Server. I'd be fine if we wanted to document that older versions of SharePoint Server should still run this command on all front-ends, but it's no longer needed for SharePoint Server 2019.

Thanks @TroyStarr PR is on the way.
@fowl2 James I hope this explanation directly from the team clarifies it to you! 👍

[fowl2]

It's definitely an improvement, thanks :) I'm upgrading a single server 2013 farm so nothing applies to my current situation yet though 😅😅. I'll probably just take my chances without the iisreset honestly, as it seems to work #yolo.

Back improving the article - The wording is still a little ambiguous to me about about what "for the site move to take effect" means. Perhaps something like:

In SharePoint 2016 and prior users may experience issues accessing moved sites. This can be resolved by recycling the the affected application pool(s), for example by using either the iisreset or Restart-WebAppPool on commands on each of affected farm member servers. Note that this a potentially disruptive operation to all sites hosted on those application pool(s)/servers, not just the moved site(s).

Possibly related is Reset-SPSites added in SharePoint 2016.

[fowl2]

Update: just found this doc that states that iisreset is not supported? (Emphasis mine.)

IISReset.exe is a command-line utility that was introduced in IIS 5.0 that could be used to stop, start, and restart IIS Internet services. Its use is not recommended for IIS 6.0 and is not supported in IIS 7.0 or IIS 7.5.

[yogkumgit]

@get-itips Thank you very much for the contribution and updating the documentation with PR. @fowl2 Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.

[fowl2]

@yogkumgit looks like you missed my comment, thanks =)

[tseward]

@fowl2 per https://techcommunity.microsoft.com/t5/iis-support-blog/iisreset-internals/ba-p/951578, you can use in a supported method iisreset given you use the /noforce switch.

[fowl2]

@tseward That's a great little extra piece of the puzzle, thanks! Definitely should go into this article.

I'm not sure where the official, live IIS docs live, but hopefully we can get all this info consolidated into docs.microsoft.com.

[get-itips]

@fowl2 per https://techcommunity.microsoft.com/t5/iis-support-blog/iisreset-internals/ba-p/951578, you can use in a supported method iisreset given you use the /noforce switch.

Great find @tseward
Given the information we could gather inside this thread and that the questions has been answered, I think we can proceed closing this thread.
This thread will remain at the bottom of the article in case any other user has the same questions.
Thank you @tseward @TroyStarr @fowl2

[tseward]

Agree. @fowl2 you'll note in that TC article states that the 'unsupported' factor comes from cutting off the IISADMIN service. We're attempting to find out if this is _important_ or not as it relates to SharePoint -- it may not be, which means a plain iisreset would be OK.