Tag Info

Hot answers tagged

9

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 ...


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 ...


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 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 : ...


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

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


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 ...


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

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 @NaupilusTrevor 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

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 ...


3

Backup-SPSite will move all your data and rights and create corresponding records in the content DB. Import-Export is not so good way for you, you can use it only for web, not for site collection, but it also will move all your data and security, if you will set corresponding flags, it has a lot of options. Previous approach is also possible, you can attach ...


3

Sorry to resurrect such an old thread however I ran into a similar problem today and this http://reality-tech.com/2012/04/04/gradual-site-collection-deletion/ post put me onto the solution. This meant I didn't have to install to a different content database which would have been a big headache for us. Hopefully this might help someone in the future...


3

Hi I had the very same issue after restoring. The accepted solution by user879 to this question seems to help: I can't login to SharePoint 2010, what's wrong? (answer here). You can give it a try, but be aware that disabling the loopback could pose a threat as per the article posted by James in the comment - disable loopback check & sharepoint


3

Open SharePoint 2010 Management Shell and run the following PowerShell: $docSize = 50000000 $webservice = [Microsoft.SharePoint.Administration.SPWebService]::ContentService $webservice.MaxTemplateDocumentSize = $docSize $webservice.Update() Accroding to MSDN, it should be between 0-500MB, but you can go beyond 500MB AFAIK.


3

Using the SharePoint PowerShell console Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} -Item <WebApplicationName> [-Verbose] See this MSDN article: Use Windows PowerShell to back up a Web application in SharePoint Server. Use this command to restore a content DB: Restore-SPFarm -Directory <Backup folder ...


3

The farm you received the database from is most likely at a different patch level than the farm you are trying to mount it to. Get the systems to the same patch level and then try mounting the database again. Also, you will most likely want to remove the root site collection from your development environment because if you are trying to restore a root site ...


3

Making a backup of the site collection is best used when you need to restore it on the same environment It's nearly like a content database backup. Exporting a site collection will allow you to import it on a different environment. It's working in a similar fashion than content deployment jobs. It will include in an environment agnostic way all the assets ...


3

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.


3

Check if you're having sufficient permissions in SQL server to perform restore Double check the managed-path try restoring to different paths like http://servername.com/sites/yousitecollection Ensure all the customizations (WSPs) are deployed to destination (if any). Check ULS logs for additional pointers


3

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


3

Couple of things to check: Make Sure Farm admin accounts having the write permission on the path. try to use different path Make sure the site is not locked check the ULS / Application Logs for clue. Also try to take the backup from powershell to isolate the issue. Backup-SPSite -Identity <SiteCollectionGUIDorURL> -Path <BackupFile> Some IIS ...


3

You try to restore a site collection backup to the same content database from which the site backup was taken , there will be a GUID conflict. GUID for a site collection is unique and it gets stored along with the site collection backup.



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