Using Invoke-SPOSiteSwap to Swap in a New Root Site in Office 365 – Follow Up
Last week, I wrote a post about using Invoke-SPOSiteSwap to swap a new modern site into the root site of our Sympraxis tenant. While it worked just great, there were some follow on issues I wanted to document in case you might run into them, too. Nothing horrible, but a bit of required cleanup.
The old classic site we had in the root had subsites. I had been syncing the libraries in some of those subsites with OneDrive, so there were nice folders showing up in Windows Explorer where I would do my work with those files. After the swap, I started getting errors from OneDrive which were a little confusing.
While the error was saying :
We can't reach this library because of a service Issue. Restart OneDrive to try again.
…in actual fact, those libraries simply weren’t there to sync anymore. No matter how many times I would restart OneDrive (and I did once before I realized the problem!), those libraries were never going to start syncing again. Instead, I needed to go into the OneDrive settings and Stop sync for the libraries which weren’t there anymore.
Then I just navigated to their new location and started syncing again. This is certainly an argument for not using subsites anymore.
You might say “Well, of course, Marc! This is all your fault!” Well, sure it is. But the errors didn’t tell me the right cause, so it might be useful for others to know what it means.
In the SharePoint Dev Weekly – Episode 49 call this week, Vesa Juvonen (@vesajuvonen) and Waldek Mastykarz (@waldekm) talked about the fact that links will NOT be fixed up in the site swap (43:11). I had been under the impression that they would be. This didn’t bite me in particular, but it’s something to watch out for.
Vesa also mentioned (46:23) that the Invoke-SPOSiteSwap cmdlet is currently hard-wired to prevent you from using it to swap a site into any location other than the root site. In my usual “trust but verify” mode, I tested it, and what he says is indeed true.
You end up with an error like:
Invoke-SPOSiteSwap : The target URL must be the root site or the search center site At line:1 char:1 Invoke-SPOSiteSwap -SourceUrl https://sympraxis.sharepoint.com/sites/ …~~~~~~~~~~~~~~~~~ int.PowerShell.SwapSite CategoryInfo : NotSpecified: (:) [Invoke-SPOSiteSwap], ServerException FullyQualifiedErrorId : Microsoft.SharePoint.Client.ServerException,Microsoft.Online.SharePoint.PowerShell.SwapSite
All in all, still a successful exercise. Happy swapping!
When you did your SiteSwap i noticed a few things that i cant find any info on. I did not see your left navigation bar on the modern site. Do you just have to re-enable that? Does it copy or move all your info (Document Libraries, Lists, Calendar, Etc..?) If not how do you get all that old info into your new site? Thanks
@Anthony:
When you do a Site Swap, you’re literally swapping the site into the root location. so everything in the SourceUrl site moves into that spot. You’ll probably want to have everything set up in that site before you do the swap.
Hi Matt,
Nice post! Currently we can do the SiteSwap in our test tenant with just 25 seats but in our prod tenant with 5000 seats it still says, Invoke-SPOSiteSwap : SwapSite operation not yet supported.
I read somewhere that MS is rolling-out small tenants first but it should be finished in October. I guess I need to be patient but it’s so hard :-)
Do you know anything regarding this roll-out strategy. Our tenant is in Western Europe.
Thanks,
Maarten
@Maarten:
The party line is they have rolled out to tenants up to 10000 users now. Have you checked recently? I expect if you put in a ticket, you can get it activated if it isn’t already.
M.
Is there any down time during a site swap when it involves the root site? When a root site is deleted, this action causes all of SharePoint and Teams to go down for the tenant. Just want to make sure such a thing isn’t possible performing a site swap on a tenant?
@Jono:
I haven’t see things go down when deleting the root site, but it’s not something one usually does. Using SPOSiteSwap should be an unusual occurrence, and you should plan accordingly. You’re changing the root site, and probably substantively, so you should treat it the same way you would any other major change. You’ll need some sort of change management plan and communication plan so people know the new site will be there after XXX date. I would think that – for the most part – you’d do a site swap after hours or over a weekend to allow for validation and testing.
M.
Hey Marc, It would be good to know if we can reverse the swap if there are unforeseen difficulties (par for the course for Msft). I assume so, but wondered if you know anyone who’s tried it? Regards!
You certainly could swap out again, but IMO, it would be better to just fix whatever issues you have.
Thanks for the tip about getting rid of that OneDrive error. I’ve been trying to figure out how to deal with that and your blog was the only thing that helped. Cheers.
Hi Marc, Hope you can point me in the right direction.
I am unable to swap the root site using the SPO admin centre or the invoke-spositeswap command.
Keep getting the error “The page diagnostics for SharePoint tool needs to run to validate the home page” if I run the tool I don’t get any errors, I have even attempted replacing the root site with a blank site that basically just has a blank template applied and I still get that error, has anyone ever had this issue before? Not getting much help from Microsoft with this.
Clayton:
Does this other post help at all?
SharePoint Site Swap Fails – But a Fallback Position When we build a new Home Site in a client tenant, usually for a new Intranet, we generally build that new site off in a corner, so it’s not exposed … https://sympmarc.com/2024/01/26/sharepoint-site-swap-fails-but-a-fallback-position/
M.
Thanks for the quick reply Marc,
Unfortunately the client requires the url to be the root site, so I cant use the current url.
The new site is a like for like copy from a classic site to a new modern site, which means all published URLs to policy documents for example need to be the same.
I am not getting a max url length error but will run the script you have published and start from there.
Thanks for your guidance