I'm totally new to sharepoint, My question is simple. I have a document library with some documents in it. When I delete a document from the library, this document still appears in search results. I solved this by running something called full crawl, I honestly don't know what this is. Do I have to do this every time I modify the documents in the library?
Reset your index, good guide here :)
http://sharepointnoob.wordpress.com/2009/05/27/reset-crawled-content-in-moss-2007/
Check the crawl logs for errors during the crawl.
Also try
Go to SharePoint Central Administration > Operations > Services on Server, stop the Windows SharePoint Service Search service
Started the Windows SharePoint Service Search service from SharePoint Central Administration and create a new search database
Re-associated the indexer to the content database from SharePoint 3.0 Central Administration > Application Management > Content Databases
Make sure that your crawl account does not have administrator level privileges to your SharePoint farm. If it does, it can see deleted items and can cause this issue to occur. It should just be a default user account with read permissions.
Yes, I guess you have to do this every single time you do any modification. At least this is how I do it/
Related
I have a user that is getting alerts from TFS. When I looked at [Tfs_Configuration].[dbo].[tbl_Identity] I found several people that I have no idea how they got in there.
When I do a backup of the TFS server through the console, they get an email notification.
How do I remove them? I have tried attempting to sync with JobService, rebooted the server, looked in AD at the person, and I've looked in TFS in User Management in the Console. They are not there. I can find them in TFS if I search for a Subscriber on a Project, but nothing in regards to backup or the like or a way to remove them from the entire TFS instance.
I have also looked a the Console and group membership for individual projects. They are not Team Foundation Administrators.
You do not: TFS/VSTS/ADO needs to refer to past users reference in work item, version control and other subsystems.
You can break your database in an unrecoverable way modifying the tbl_Identity table.
The only reasonable thing to do is to remove these users from all TFS (and Active Directory) groups so they only appears in old data. The TFSSecurity utility can help you identify which groups has a specific user.
I'm trying to migrate content from one MOSS farm to another. Specifically a web application. The web application data is fully contained within a single content database. My process for doing this is as follows.
SQL backup content db from source sql server
Copy bak file over to destination sql server
Restore database from bak file on destination sql server - WSS_Content_DB
Create new web application on dest MOSS farm (http://newmoss:1234/)
Create root site collection
Via central admin remove the content database from new web app
Via stsadm add the content db (WSS_Content_DB) to http://newmoss:1234
As far as I can gather from online guides this process should work and result in the content from my source MOSS web app duplicated on the new MOSS web app.
The problem is, when I now browse to http://newmoss:1234 there is no content. If I manually add /_layouts/viewlsts.aspx to see the "View all content" page I see a few core libraries but nothing from the source web app. If I query the database though the content is there, it's just not wired up correctly.
Can anyone tell me where I am going wrong or offer me some guidance.
The database is around 600GB so fairly large. I've tried doing this backup/restore via STSADM as well but that failed during the restore process.
EDIT
I think I can see something strange when looking at the actual contents in the content database. The number of sites reported by central admin in the content database is 1. That matches what I see in the site collection list for this web app - one single root site collection.
When snooping around in the content database I can see several records in the "sites" table. This is strange as I would only expect to see a single site as per what Central Admin is telling me. Also when looking at the site ids in the database, and the site id of my broken restored site, it actually looks like the site that has restored is not the site I want! There are 5 records in the sites table and the restored site id matches the first record. The site I actually want (based on the column "Disk Used") is the third.
Any ideas what these other sites are and how I can restore a specific site?
According to https://sharepoint.stackexchange.com/questions/22150/content-db-restore-returns-0-sites, you cannot restore a content database from a site to a different site on the same farm.
Our team has a sharepoint website and I need to maintain the shared documents on our site. Problem is, it was designed by someone else and I was just given the link to the team website. I have tried using search and setting alerts and both of these don't work. i googled trying to find out what's happening and everyone keeps asking me to go to central administrator. I don't see central administrator anywhere in the website(I have full access). I am thinking I have to go to the server where sharepoint is running from. How do I figure out where it is running from? Sorry, I'm new to sharepoint.
Central Admin is the website that SharePoint creates when you install the software. It generally runs on your main SharePoint web frontend. If you RDC to your main web front end and then click on Start, All Programs and then click on the SharePoint folder, you'll see Central Administration. Click on that and the website will appear. You must be a farm admin to be able to access the site.
It sounds like you may not be a farm admin though. Depending on the permissions you have, you should be able to see your team site's Shared Documents or other document libraries under All Site Content, which you can either see by clicking on Site Actions or find it on the bottom left of the web page (again depends on what modifications have been created).
You need to assign the sign-in user account the permission to check the Shared Documents and you need to get at least Contribute permission level to maintain the Shared Doc on the site.
For Central Administrator, you can either RDC to the Web Front End server where the SharePoint was intalled or visit that server IP:port or computer name:port(80 by default).
Hope this may help!
First of all,the link you got may not be a Central Administration link.It is probably a common site collection.If you have full control permission over this site collection, you should be able to maintain Shared Document.
About the question that where SharePoint is running from?
SharePoint must be installed in a server. Generally, only farm admin can access this machine. If you want to know or learn about it, and if you don't have farm account to access the server, you can contact your farm administrator.
Central Administration is also a site.But it is different. You can manage all web applications and site collections in Central Administration.So you can manage or modify your team site in Central Administration
Hope this helps.
I've just completed an installation of SharePoint Foundation 2010 and I can't get searching to work.
In Central Administration, there is no service application listed for search.
When I go into the Manage Content Database Settings page, the option "Select Microsoft SharePoint Foundation search server" is greyed-out.
In the Services MMC, "SharePoint Foundation Search Service V4" is listed as disabled. I can get this service running for a short time, but eventually it stops and automatically reverts back to the disabled state.
What did we do wrong to make searching completely unavailable in our SharePoint Foundation 2010 installation? How do we get it fixed?
EDIT--->
I changed the log on account for "SharePoint Foundation Search V4" service. The service now starts automatically and is no longer disabled. However, when I go to Central Admin->Manage Service Applications, I still don't see a search service listed. I also still cannot assign a search server to the content databases.
I've tried repairing the SharePoint installation and rebooting the box. I feel like I'm one step closer - but I still don't have search functionality on the site.
EDIT #2--->
I checked the databases on this system and there is no search database listed. On our old WSS 3.0 system there was a database dedicated to search for SharePoint. I'm not sure if this database is missing from the 2010 Foundation server or if 2010 doesn't use a separate database anymore?
I've now got the search service running on my SharePoint Foundation 2010 Installation. Here's what I did:
In Central Administration, go to System Settings->Services on Server. (Note: Prior to this step - no WSS_Search_* database existed on the server)
Select the SharePoint Foundation Search service and click Start
Enter and/or confirm the settings on the Search service page
Press Start to start the service
Go to Manage Content Databases
For each content database in the SharePoint site - assign the correct search server (Note: This option was greyed out until after I started the service in "CA->Services on Server")
At this point search is now enabled on the server. I've verified that search is working correctly. However, I do note that the search service still does not appear in the CA->Manage Service Applications list)
With Sharepoint Foundation you must install Microsoft Search Server http://www.microsoft.com/enterprisesearch/searchserverexpress/en/us/download.aspx
Whats the best way to deploy a webpart in WSS3 or MOSS2007 which has a database dependency? Should the .wsp include code to create the database, should I encapsulate the .wsp in another installer which handles the database creation, or should I supply two different packages to allow the admin to handle the backend creation?
Well, I prefer the SharePoint way where you create the databases from a SharePoint admin page in Central Administration. Just take a look at how SharePoint handles the creation of new Web Applications where you are asked to name the database server and the name for the SharePoint content database.
In other words, I would opt for a WSP only deployment. The WSP should include a database configuration page (an ASPX page) plus a farm level feature for installing a custom action link to the page inside Central Administration. The beauty of doing it from Central Admin is that it runs in a context with privileges to create new databases on the SQL server. Hence, you do not need to ask the user for login and password to the database server.
The configuration page should upon successful creation of the database persist the connection info in the SharePoint configuration page, using a custom derivative of the SPPersistedObject class. Web Parts can in turn read these settings to connect to the database.
MSI installers should in my opinion be avoided when designing SharePoint apps.
What sort of client is your webpart aimed at?
I imagine it might be worth being slightly flexible in your approach and considering multiple methods of installing your webpart.
So for someone without a dedicated DBA it might be best to have one .wsp.
(Although this should be robust enough to handle superuser's installing it.)
Alternatively go for a .wsp and a msi (or even scripts), which will give the installer
more control over exactly how it is installed.
(I'd prefer this approach, over the .wsp only approach.)