I'm in a machine that has already SharePoint installed, so when I started the SharePoint Central Administration to config, this message appear to me: "Can not connect to the database configuration."
How do I know which database is configured SharePoint?
Normally the Admin database is created using the naming convention SharePoint_AdminContent_{GUID}. However if there's more than one, you'll need to use SQL Management studo or other tool to look inside the DBs, look for a table called "DatabaseInformation" which will contain two items, look in the AlternateAccessMappingXML entry and look for the XML tage IncomingUrl, that should help you narrow it down.
Or just use the SQL profiler and watch for connections.
By default SharePoint will install the Database on the same machine as the web server, but you can ask whoever installed SharePoint on the machine.
Anyhow, most likely it's not relevant and something else is the problem, follow the resolution methods described here and you'll probably have it fixed.
Related
I am trying to remove on of the servers on My farms but I ma not able to do it ,please check this Image :
When I Click on "remove Server" I get this error :
An object in the SharePoint administrative framework, "SPDatabaseServiceInstance", could not be deleted because other objects depend on it. Update all of these dependents to point to null or different objects and retry this operation
Or at less is there a way to know what are the dependents on that server ?
thanks and best regards.
If it is possible, I would connect to the database server to remove and using Management Studio I would check if there is some sharepoint databases running.
Then you can move existing databases to another sql server.
This post helped me a lot to do it :
http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=255
(it is for sharepoint 2007 but process is the same)
I recently inherited an application from a developer who is no longer with the company. This application restores SharePoint sites from backups and extracts metadata and files from lists in the site. The application runs on a SharePoint server and uses the Microsoft.SharePoint assemblies in C# and VB.Net.
The backups come to us from various outside companies, and some of them have custom features installed. SharePoint Health Analyzer shows a warning about "Missing server side dependencies". When I look at the report there is a lot of "[MissingFeature] Database [db name] has reference(s) to a missing feature..." etc. The previous developer was supposed to implement a check for missing features, but it is obviously not working.
How can I identify features that the restored site references, but are not installed on the farm?
Thanks!
RH
You can use SQL Management Studion and check Features and FeatureTracking tables to see list of features, its' IDs, titles etc.
But do not modify these tables.
To solve missing features error. You can:
1. install missing feature (if you have it).
2. try to remove it (probably will fail as you don't have it).
3. as the last chance option you can create empty feature with the same ID as missing feature, pack it in WSP package and install it.
I'm looking for a way to duplicate the content of a SharePoint 2010 server in order to work against it without taxing the main (production) server. I would need the backup server to update as needed, but I'm not looking for a failover solution. It looks like 2010 includes replication features for failover, but I can't tell if this is appropriate for my solution as well (simply not configuring the switchover feature). Can someone with SP 2010 experience tell me if this feature would work for my needs?
You could attach a restored backup of your production content database. See this MSDN documentation for more info: Attach or detach content databases (Sharepoint Server 2010).
There is also a GUI tool http://sushi.codeplex.com/ which should help you. You could backup production and restore to dev site whenever you needed to.
You could also use either stsadm.exe and the backup/restore option OR the powershell cmd backup/restore.
In addition, there is a built in interface in Central Admin to backup/restore sites. I've generally found either the command line or the SUSHI tool to be quicker and easier.
In most cases, the taxing work is on the sharepoint side, not the SQL side. You could attach another front end to the farm but reserve it for only your traffic. Otherwise you're looking at some form of backup/restore to copy everything to a 2nd duplicate farm.
I have installed and configured SharePoint 2010 to run on the same box as the SQL Server its running from in Windows Server 2008 R2. Everything is working fine except the search. I have uploaded several documents and tagged several items (documents, tasks, announcements etc), however whenever I search the site using the defaul search, i get nothing returned no matter what i search on, I simply get "We did not find any results for [search term]". I know there is setup needed if you wish to use "FAST search", but do I have to do anything to get the standard default search to work?
Found the answer on SharePoint.SE:
After installing the system you need to configure your indexing job.
Navigate to CA > Service Applications > Search.
You will see a link to your Content Sources. If you edit that it will give you the opportunity to setup a schedule for both Full and Incremental indexing.
You can kick off a full crawl, once completed you will have results if everything is configured correctly.
It does work for people search too . if you edit this content source you will see sps protocol which is for user profiles .
To make people search to work, in Central Administration > Manage Service Applications, make sure to provide a valid domain\user account as administrator in User Profile Service Application.
To add on to Chensformers answers, the account has to have "Retrieve People Data for Search Crawlers" enabled. They have to have it in the Administrators button, even if the Permissions is set to Full Control! Quite misleading.
I'm in the process of moving a complete sharepoint install to a different server.
Can anyone tell me if it's possible to just move the existing Shared Services Provider rather than starting from scratch?
All the best
You really need to move the SSP in concert with everything else in the farm. The two things to move are 1. databases and 2. the file system.
A .doc file for moving all of the SharePoint databases has been published here. Microsoft will soon have an updated procedure for this published on TechNet, according to the To The SharePoint blog.
Then to cover off any file system changes, I would set up a clean install of SharePoint (if you didn't need to already by following the document mentioned above) and do a file comparison between your source and destination SharePoint application servers. I usually use WinMerge as its free but Beyond Compare is also good. Also check any custom solutions are deployed on your destination server.
By ensuring your databases are moved correctly and all of your files are in place you should be OK. Make sure you test every custom component on your destination server before erasing the source databases and files (even better, archive the source).
Yes, create a new SSP and move the applications.
How to on migration of applications here
For moving the SSP to a new farm
Or try the Microsoft SharePoint Administration ToolKit v2.0
For another view of this