I have a SharePoint 2013 site collection backup and i am trying to restore this back up on another SharePoint 2013 site collection. Both SharePoint sites are on the same domain. But when i try to restore the site collection from backup, i am getting an error as -
Restore-SPSite : <nativehr>0x80070003</nativehr><nativestack></nativestack>
At line:1 char:1
+ Restore-SPSite-Identity http://ksptestinst2:9999 -Path
"E:\SiteBackup\BackupSPS ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+ CategoryInfo : InvalidData: (Microsoft.Share...dletRestoreSite:
SPCmdletRestoreSite) [Restore-SPSite], DirectoryNotFoundException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRestoreS
ite
the command i use to restore site collection backup is -
Restore-SPSite -Identity http://ksptestinst2:9999 -Path "E:\SiteBackup\BackupSPSite.bak" -Force
i tried using
Restore-SPSite -Identity "http://ksptestinst2:9999/" -Path "E:\SiteBackup\BackupSPSite.bak" -Force -DatabaseServer KSQL2012SP\SQL
TESTDB -DatabaseName WSS_Content_KSPTESTINST2_9999
but both commands are giving same error.
Can anyone suggest how do we proceed?
Couple of Approaches that you could try:
1: Run SharePoint Config Wizard on both the servers
There could be server patches installed, SharePoint services installed, SQL patches installed, pending restarts or any other factor that you might want to rule out initially. Then perform a backup and restore operation. This is an easy one to cross off the list (quite often overlooked).
2: Match Environment Patch Levels
The best & recommended fix is to ensure that you match the SharePoint Configuration Database versions and/or Cumulative Updates/Patch levels to match both the environments- the environment from where you took the backup might be at a different patch level than the environment you are going to restore the patch to. (Goto Central Admin –> System Settings –> Manage Servers in this Farm and verify if there is any pending action. Keep not of the version to verify any version mismatches between environments)
In the same page, double check that you do not see any “Upgrade Required” mentioned against any of those servers. If it is mentioned there, please ensure that you run the SP Config Wizard before you proceed.
Once things look good, and you have compared the versions, download the latest KB from Microsoft and install them to match the SharePoint Configuration Database Schema versions. Perform all server remediation & CU (Cumulative Updates) installations. Remember to run the Configuration Wizards for each CU.
3: Using STSADM
This is a pretty interesting workaround. But sometimes I feel “Old is Gold”. Power up your SP Management Console and try to perform the restore operation using the good old STSADM command line. At times, when the new powershell commandlets fails, stsadm has worked for me.
stsadm –o restore –url "site url" -filename "backup filename"
4: Content DB Restore
Try a Content Database Backup and restore. Before doing this you might want to check in Central Admin (View All Site Collections –> Select the Site Collection and check the Content DB on which it is installed on) about which all site collections will get affected if you restore a particular Content DB. You do not want to lose any other Site Collections that shares the same Content DB.
5: Editing Backup File
(Not Recommended - But works like a Charm)
This is one of those quick and untidy fixes you could possibly try. To start, open the backup file (file you got from the Backup-SPSite command) in Notepad++. (or any other text editor; avoid Notepad though). It might look funny with special characters, but ignore all those for now.
If the file size is too large to open in Notepad++ (>100MB), you can use any standard File Splitter Program to split the file into multiple smaller files of say 10 MB. I have had success with FFSJ
When you edit the file (if you have split the files, open the first split file) in Notepad++ and look for version number that looks something like 15.0.XXXX.XXXX. It should appear somewhere in the beginning lines.
DO NOT MODIFY ANYTHING ELSE. Interestingly, this is the version number that the Restore-SPSite Commandlet checks initially. And if it sees the server version different from the backup version, it just throws the error
Now to know which version number to put there, all you have to do is open your ULS logs (15\Logs{latestlogfile}) and search for a text "schema version". You should see a message similar to this:
Could not deserialize site from E:\SiteCollection1.bak .
Microsoft.SharePoint.SPException: Schema version of backup
15.0.YYYY.YYYY does not match current schema version 15.0.XXXX.XXXX at Microsoft.SharePoint.SPSite.Restore(String filename, Boolean
isADMode, Boolean& readOnlyMode, Boolean& hadWriteLock)
If you are unable to find the above message in the logs, then the issue would be probably something else and there is little/no chance to get this option to work
If you succeed in finding the error message, pick the version number it was expecting from the above ULS error message and update the VERSION NUMBER ONLY in the backup file you were editing in Notepad++. Save it. If you had split the files using a file splitter tool, merge the files back into a single backup file.
Now run the restore command with the new backup file and see if it works.
Restore-SPSite -Identity {{SiteCollectionURL}} -Path "E:\SiteCollection1-New.bak" -Force
These are just a few of the options (not an exhaustive list, but hopefully a good start) that you could try.
I have had greater probability of success with option #1 & #5. Option #2 is something that should be done in the long run.
You could read a bit more on this from my post here as well.
Related
After going through a windows 10 re-installation due to a windows update crashing my laptop, I was left with re-installing many applications. One of them being node.js. When I tried to install it through the windows installer, I kept getting 'setup wizard ended prematurely because of an error message'. I am not sure what the problem is. I used x64 version which is what my OS is and there is no nodejs folder in program files. When I logged the installation this message popped in a lot of the lines has no eligible binary patches. Before the no eligible lines there were error logs such as:
'WixSchedInternetShortcuts: Error 0x8007000d: failed to add temporary row, dberr: 1, err: Directory_'
'WixSchedInternetShortcuts: Folder 'ApplicationProgramsFolder' already exists in the CreateFolder table; the above error is harmless'
If that is not enough information please advice me on how to send the full logs without spamming huge text in the thread. Thank you.
The MSI log file:
https://gist.github.com/luki2000/ab00476127d54aaf610d8bda84d40a64
Maybe try to search the log for "value 3" as explained by Rob Mensching in his blog. Doing so will find the locations in the log file that describe errors of significance.
Many people use dropbox, gdisk or similar to post logs. Some put it on github (just a sample log for OP, leaving in for reference). Check that last link, is that the same problem you see perhaps? (search for "value 3" as explained above - without the quotes of course). Looks like there is an error creating an Internet shortcut. Perhaps that is a Windows 10 problem? I will take a quick look.
I am betting Bob Arnson knows what this problem is outright. He will probably give us the real answer, see below for my workaround.
The correct thing to do overall, would probably be to communicate the problem back to the Node.js guys so they can fix the problem once and for all.
UPDATE: Maybe see if this answer helps you: node.js installer failing with 'CAQuietExec Failed' and 1603 error code on Windows 7. Essentially un-check Event tracing(ETW) in the setup's feature dialog - or you can try to launch the MSI from an elevated command prompt.
UPDATE: There seem to be two Internet shortcuts configured for this MSI in the WixInternetShortcut table. I would just create a transform to remove these two shortcuts and try a reinstall. If you feel bold and fearless and like to break the law, you can delete the two rows from the table and just save directly to the MSI itself. This is never the right thing to do if you are a deployment specialists. The original MSI is sacred, but if this is for your own system and you need to get something done, that would work. Then you just install the MSI direct afterwards. Otherwise you can install the transform after creating it with a simple command line:
msiexec.exe /i node-v8.11.2-x64.msi TRANSFORMS="C:\MyTransform"
You can create the transform using Orca, InstEd or SuperOrca or any commercial tool that supports creating transforms.
In case you don't know, transforms are little database fragments that are applied to the original MSI (which is also a database under the hood). After the transform is applied the in-memory version of the MSI is the MSI + the changes from the transform.
I modified a lot of options in IIS, and would like to reset its settings to default.
I already tried installing/reinstalling it. After the reinstall, it still had the site I created. It was still breaking on the setting I made to the DefaultWebSite.
People suggested uninstalling Windows Process Activation Service first, but it seems like it wasn't installed anyway, so I can't really uninstall it.
How can I reset this installation of IIS back to an out-of-the-box state?
You need to uninstall IIS (Internet Information Services) but the key thing here is to make sure you uninstall the Windows Process Activation Service or otherwise your ApplicationHost.config will be still around. When you uninstall WAS then your configuration will be cleaned up and you will truly start with a fresh new IIS (and all data/configuration will be lost).
There are automatic backup under %systemdrive%\inetpub\history but it may not help much if you already made lots of changes.
http://blogs.iis.net/bills/archive/2008/03/24/how-to-backup-restore-iis7-configuration.aspx
You will have to regularly back up manually using appcmd.
If you try to reinstall IIS, please first uninstall IIS and WAS via Add/Remove Programs, and then delete all existing files under C:\inetpub and C:\Windows\system32\inetsrv directories. Then you can install again cleanly.
WARN: beginners on IIS are not recommended to execute the steps above without a full backup of the system. The steps should be executed with caution and good understanding of IIS. If you are not capable of or you have doubt, make sure you open a support case with Microsoft via http://support.microsoft.com and consult.
What worked for me was going to the article someone else had already mentioned, but keying on this piece:
application.config.backup is not created by automatic backup. The backup files are in %systemdrive%\inetpub\history directory. Automatic backup is also a Vista SP1 and above feature. More information can be found in this blog post, http://blogs.iis.net/bills/archive/2008/03/24/how-to-backup-restore-iis7-configuration.aspx
I was able to find backups of my settings from when I had first installed IIS, and just copy and replace the files in the inetsrv\config directory.
Source: http://forums.iis.net/t/1085990.aspx
There is one way that I have used my self. Go to Control Panel\Programs\Turn Windows features on or off then uninstall IIS and all of its components completely. I restart windows but I'm not sure if it's required or not. Then install it again from the same path.
This link has some useful suggestions:
http://forums.iis.net/t/1085990.aspx
It depends on where you have the config settings stored. By default
IIS7 will have all of it's configuration settings stored in a file
called "ApplicationHost.Config". If you have delegation configured
then you will see site/app related config settings getting written to
web.config file for the site/app. With IIS7 on vista there is an
automatica backup file for master configuration is created. This file
is called "application.config.backup" and it resides inside
"C:\Windows\System32\inetsrv\config" You could rename this file to
applicationHost.config and replace it with the applicationHost.config
inside the config folder. IIS7 on server release will have better
configuration back up story, but for now I recommend using APPCMD to
backup/restore your configuration on regualr basis. Example: APPCMD
ADD BACK "MYBACKUP" Another option (really the last option) is to
uninstall/reinstall IIS along with WPAS (Windows Process activation
service).
Resetting IIS
On the computer that is running Microsoft Dynamics NAV Web Server components, open a command prompt as an administrator as follows:
a. From the Start menu, choose All Programs, and then choose Accessories.
b. Right-click Command Prompt, and then choose Run as administrator.
At the command prompt, type the following command to change to the Microsoft.NET\Framework64\v4.0.30319 folder, and then press Enter.
cd\Windows\Microsoft.NET\Framework64\v4.0.30319
At the command prompt, type the following command, and then press Enter.
aspnet_regiis.exe -iru
At the command prompt, type the following command, and then press Enter.
iisreset
I've been developing a new SharePoint 2010 package in Visual Studio 2010. This is my first development project in SharePoint so please pardon my use of incorrect terminology.
Within the package/solution there are a couple of Features, a couple of custom web forms, and a workflow for the custom list type which is also within the solution.
To develop and debug I've been simply using the Build > Deploy Solution option from within Visual Studio to build the solution and then it would automatically connect to my sharepoint server and create the custom List, install the features, add the workflow, etc.
But when I want to make a change, say change the color of the text on the custom NewForm (mine is called MyCustomForm.ascx) then I click Build > Deploy Solution it deletes the custom list, deletes the workflow, deactivates and deletes the features and then re adds them all again. Thus I lose all of my list items.
In production if I need to modify the workflow I can't simply do this as we would lose all of our list items. How can I do this?
I've done days worth of research and nothing works. I've looked into:
stsadm -o upgradesolution -name SharePointProject1.wsp -filename ...
stsadm.exe -o execadmsvcjobs
with no avail. It says everything "works" fine (no errors) but doesn't update the custom MyCustomForm.
I've also tried manually editing the files in:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES
to no avail as well. I modify the MyCustomForm.ascx file and refresh the SharePoint site page and it hasn't changed.
Any insight would be helpful. I am doing all development on the server machine that is running SharePoint and have admin access if that helps. Thank you in advance for all of your help.
The list is deleted because the solution package that you're deploying has the list item in it so Visual Studio is "helping" by making sure that you get the lastest version of everything (even it it hasn't changed)
There are two approaches you can take to over-ride this behaviour
Set the deployment model to "No Activataion" this will result in the package being deployed and leaving previously deployed and activated feature in place.
Remove the list instance item from the package by double clicking on the Package in the Solution Explorer and then double clicking on the List Instance Item in the right hand pane.
Next time re-deploy the solution you not should have your existing list removed (I'm not 100% on the workflow association behaviour).
Of the two I'd lean towards option 2
I am trying to take a backup and restore a site collection on my SharePoint 2003 Server environment using the STSADM utility. I was able to create a backup of my top level site which contains a document library of 2000 items. The utility completed successively generating a back up file around 2Gigs in size.
When i try to restore the site the utility gives an Operation Aborted message. Is there a log that is generated that gives better insight into why the restore operation failed?
Try the ULS logs as usual in the first instance...
You should monitor your SQL server. When doing backup and restores, TembDB takes a bit of a hammering, as does the database where your site is being restored. Ensure that everything has space to grow sufficiently (this may be more than you think - I've experienced the need for greater than 3 times the source data size).
If things should fail on the SQL end, this should be reflected in Application or SQL error logs on the SQL instance.
Are you renaming the site when you restore? If you are making the site name longer you may be running into limits over path lengths.
I have 12.0.0.6421 showing in Central Admin, which would seem to indicate that SP2 was installed. However, when I run an STSADM command to backup a site collection, I do not see the message informing me that it's "setting the site collection to be-read only for the duration of the backup" as described here:
http://bobfox.securespsite.com/FoxBlog/Lists/Posts/Post.aspx?ID=121
I simply get the "Operation completed successfully" message I used to get pre-SP2. Does this mean that SP2 wasn't installed correctly?
Anthony,
Showing a build of 6421 does indeed indicate that SP2 is in-place. Just to make sure, I checked my own farm and VMs as well as a reliable external source (an entry from Todd Klindt's blog: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=154). I didn't doubt the build number, but it never hurts to confirm :-)
At first, I thought I understood where the issue might be, so I ran some tests. First, I ran an STSADM backup in catastrophic mode to backup my entire farm. Since this isn't a site collection backup, no locking should occur:
stsadm -o backup -directory \\ss-nas3\backups\test -backupmethod full
My catastrophic backup ran without issue, and I didn't receive any message about a lock or read-only behavior. I looked at my ULS logs, as well, and confirmed that no lock was being established (searching for "sitelock" and "lock"). This was as I expected, as I was doing a catastrophic backup -- not a site collection backup.
Next, I tried a site collection backup:
stsadm -o backup -url https://www.sculpted-system.com/pictures -filename \\ss-nas3\backups\test\SiteCollectionBackupTest.bak
Strangely enough, I didn't see a locking message here, either. I took a look at the ULS logs, and I saw nothing to indicate that a lock was put in place. Finally, I performed an
stsadm -o getsitelock ...
... while the backup was running and was greeted with this:
<SiteLock Lock="none" />
ARGH! That's not what I wanted (or expected) to see! Clearly, there was a problem ... so, I tried coming at it from a different angle. I took a look at the MSDN documentation for the STSADM -o backup command, and it clearly indicated that a lock should occur by default. It also indicated that the -nositelock switch should work to override the behavior. So, I tried adding -nositelock to my site collection backup command line.
Guess what: it choked on -nositelock with a command line error (invalid parameter).
Doing an STSADM -help backup indicated that -nositelock was not a valid switch for my environment. None of the new switches I expected (e.g., -nositelock and -force) were present. It's as if my production farm was stuck in pre-SP2 with regard to backups.
I decided to check a development VM I had that was also build 6421 (but different image -- amongst other things, Win2K8 instead of Win2K3 R2), I saw that the -nositelock was a valid command line option. So I checked another development VM that was also build 6421 (but Win2K3 R2 like my "regular farm"). -nositelock was a valid option there, too.
I had applied SP2 the same across all three environments when upgrading (WSSv3 SP2 bits, following by MOSS 2007 SP2 bits, followed by a run of the configuration wizard), so I wasn't sure what was going on.
For fun, I ran a site collection backup on each of the VMs that correctly displayed that -nositelock was a valid command line switch for site collection backups, and I was met with the locking message I didn't see earlier (and that you weren't seeing, either). Clearly, the SP2 updates were operating as I expected them to everywhere except my primary (production) farm.
I concluded I must have somehow done something wrong as part of upgrading my farm, so I tried re-running the WSSv3 SP2 update (first) and MOSS 2007 SP2 update (second) on each box. With each update on each box, I was told the that the update had already been applied. So, I dropped back and punted: I re-ran the configuration wizard to see if it would do anything. I then rebooted the two (virtual) boxes in the farm.
No change.
At this point, I can only confirm that you aren't losing your mind. Two of my all-in-one development VMs with SP2 build 6421 operate as expected, but my two-server/VM farm that is build 6421 that should be locking on site collection backup is not.
I think I'll probably follow up with a friend who is a Microsoft TAM. If I learn anything, I'll post it here and probably on my blog. In the meantime, you might want to follow up with Microsoft, as well. Clearly, something isn't working as expected.
For what it's worth!
There is a list of SharePoint Versions maintained by the SharePoint community here:
http://www.sharepointdevwiki.com/display/SharePointAdministrationWiki/SharePoint+Versions
Your version is correct for SP2; I wouldn't worry about the STSADM message appearing; it's a pretty inconsistent tool.