Hot answers tagged

10

This is a known issue[citation needed] and unfortunately restoring to a new content database is the only workaround (I refuse to call it a solution since you now have a new problem). Once restored, you can't move the site back either; the error it returns is about how the site used to exist in the content database. If you can, avoid deleting site ...


9

I've had this discussion with Microsoft Support in June 2014. They told me that backups are performed on all site collections on a daily basis and kept for 14 days. In order to get a restore to happen you need to add a service request from your Office 365 tennant admin center (support link in the left navigation). Unfortunately they can only restore on ...


8

I just randomly came across this post and although its old I wanted to give the solution since I recently ran into this issue. To "reinstall" the built-in fields (and this should fix the field issues in the ctypes) just run the following command for each of your affected site collections: stsadm -o deactivatefeature -name Fields -url http://sitecoll -force ...


6

I recently ran into the exact same issue in SP 2013 where my Dev machine had the RTM install and the target server the June CU. We ended up copying the Content Database from SQL directly, reattaching and associating it to a Web Application and it worked flawlessly. It seems the Restore command is no longer backwards compatible and can't be relied to restore ...


6

There are a couple of things you can try... such as 1. Get-SPDeletedSite & Remove-SPDeletedSite You may already have restored this site before. In that process you also deleted the site first (automatically), which you can find running the command... >Get-SPDeletedSite You'll see the site (or sites) listed, like this: WebApplicationId : ...


6

Just look at the code snippet below and try to imagine the scenario of what will happen: using(SPSite site = new SPSite("http://somesite")) { using (SPWeb web = site.OpenWeb(SameGuid)) { return web.Url; } } The above code can raise an exception because two web objects would be returned, there are infinite scenarios where GUID is used to ...


5

You can use PowerShell to do that, check Restore-SPSite cmdlet. Restore-SPSite http://server_name/sites/site_name -Path C:\Backup\site_name.bak


5

When you delete a Site Collection, it will still remain in the Content database until the "Gradual Site Delete" Timer job is run (by default, it runs once daily). So, once you delete the site collection and run the timer job, then you can again restore the same site collection in the same content database.


5

There is just a subtle difference: Workflows are included when you use the Backup-SPSite cmdlet. If you backup a root web of a site collection the site collection recycle bin will obviously not be included.


5

there are couple of ways. Run the Test-spcontentDatabase command against the content DB to get the list use this SharePoint Feature Administration and Clean Up Tool to identify and remove them You can use the powershell to get this done. http://get-spscripts.com/2011/08/diagnose-missingwebpart-and.html


5

Did you change any modifications on front end style loading? like manipulations in . May be previous site is loading because of that resource is cached in the browser. Just clear the cache and check on old machine, if it also not working then my clue is correct.


5

Links might have broken check in the network with chrome or use fiddler


4

Saumil, that is not possible. What you coud do: * restore the content database to another sitecollection * synchronize the permissions between the two sitecollections with some custom written powershell. I don't think there's an easier way.


4

I think you will need to have some algorithm for it. Below is one which may help: Maintain the deleted sites Url and GUID in a list.You can do it using SPWebEventReceiver.WebDeleted.Also,Before it gets deleted, modify its home page to a new html like page that says "Under Construction". Create a job and monitor the list for deleted site restoration. To do ...


4

You cannot restore a content database to a prior version (major or minor). You also cannot restore a site collection. This is by design, and any attempt to change that can lead to instability and you will not be supported by MS. You will need to upgrade the destination system to the same version; SP1 and any CUs if installed. If the patch failed to ...


4

Your CSS file wouldn't be in the config db anyway, all site content (when unghosted, ie: saved through the browser or SharePoint Designer) is stored in the content database. I would check out the file, and restore each version until you get what you think is the most recent version. Do this through the UI, as SharePoint Designer is laggy when referencing a ...


4

As you need to move your SQL servers, this can and will be treated as a simple SQL server move, which requires a farm migration. This is because the domain name of the SQL server changes. For farm migration, you can find instructions at http://technet2.microsoft.com/Office/en-us/library/42511e01-ecdd-4dc5-b06f-35aaada8a5d81033.mspx?mfr=true. Make sure you ...


4

Nope, it won't work that way. You should do a backup and restore in your SP 2010 environment and put the site collection into it's own database. Then do a sql backup and restore of the database into the 2013 farm and content db attach it for it to upgrade correctly.


4

Yes, You can move it. But one thing you keep in mind if you hard coded the URL in your sites then those will cause the issue and you have to manually adjust it. Couple of options to move it. 1) Moving using the PowerShell tool. Move-Spsite Move-SPSite http://servername.com/sites/sitename -DestinationDatabase ContentDb2 Only catch in this case, you ...


4

Two easy options i am thinking about. Method # 1 Make the changes on the AAM and Update the IIS bindings. Yo may need to IIS reset at then end. Method # 2 Detach the Content Database from web App A & web App B Now attach Content DB from Web app A to Web App B & From web B to Web App A.


4

This is a common pitfall and a good reason to look into your backup routines, especially before patching as there is no way to uninstall a patch. Sadly, the only easy way would be if you have a test/staging farm where you have the same patch level as the site collection were at during the backup, restore it there and then move it to a separate content ...


3

SharePoint doesn't keep a 'version history' of content types. There's also no 'reset' option that I'm aware of. Unless you can use backups, I feel that you are faced with a laborious manual task here. I hope you have a test environment you can compare against...!


3

A couple of things here: Using backup/restore to move a site between environments is only supported under specific circumstances. For publishing sites, you need SP2 and the April 2009 Cumulative Update or later (not sure without checking version numbers if you have this). Stefan discusses this for publishing sites here, but I'm not sure how this applies to ...


3

In your example you are backing up the root site collection of machine1 and restoring it under a managed path on machine2. You may want to make those consistent. Emad is correct about step #2, as long as the application is setup on the server you will not need to create a content db. One last tip, make sure that you have any customizations or solutions ...


3

I'm not sure if this would work or not, but I wonder if you first should try creating a blank site collection in the root of the 3000 web application, and then use the -Force switch (heh, inadvertent geek humor there) with Restore-SPSite to see if you can get it to overwrite the new blank site with your backed up site collection. Just something to try, I'm ...


3

I got some help for you from twitter users @NaupliusTrevor and @toddklindt. Trevor says that error message could be occurring because the original content database has an older schema than the current patch level of the new content database. This could occur because the patch didn't change the schema of old db's when it was applied but it will create new ...


3

Another option that I have found for restoring a site collection to a different domain to the source domain (and where the source site collection cannot be set up with the site collection admin for the destination domain) is to grant the user account doing the restore access to the web application. $w = get-spwebapplication http://[urltodestinationwebapp] $...


3

This is typical (expected) behavior. You cannot attach the same content database to the same farm twice. Renaming the database will not change the object GUIDs contained within the database, so when you attach it you're essentially attaching the exact same content to a second web application. SharePoint will be unable to translate between the two since all ...


3

The way I would do this is to move the site collection into its own content database. Then copy that database and attach it to the new farm. In Central Admin add a new content database to the web application Use the Move-SPSite CMDLET in PowerShell to move the site collection to the new content database Make a SQL backup of the content database Restore ...



Only top voted, non community-wiki answers of a minimum length are eligible