This section will describe what you need to know in order to protect the SharePoint environment. There is one golden rule when it comes to SharePoint backups – make sure you can restore backups in the timeframe required by the business.
(more…)
Business Continuity is a management process that provides a framework to ensure the resilience of your business to any eventuality, to help ensure continuity of service to your key customers and the protection of your brand and reputation. In defining a SharePoint BCM it provides a basis for planning to ensure your long-term survivability following a disruptive event.
(more…)
If you are planning to install Sharepoint 2010 on Windows 7, here is an excellent article in MSDN, just follow the steps and you will end up successfully installing SharePoint 2010 beta on windows 7.
http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx
TIP: even if you follow the steps, and run the SharePoint Configuration wizard, the wizard might fail.
All you have to do is just to re-run it – it will install. I’ve noticed this seems to take place when you run into low memory issues, and the exception is stating failed provisioning on central administration.
Had a problem today where a content db migrated from a supposedly clean Sharepoint 2007 environment didn’t show up some document libraries or lists when visiting the site.
This left me really puzzled because they were visible in 2007, not 2010!! So, ok, decided to go to the rather cool ‘Review problems and solutions’ first to find out what was going on!
http://CentralAdministration:PORT/Lists/HealthReports Found this: Content databases contain orphaned items. Severity: 1 – Error Category: Availability
Explanation: In some situations, a content database that is used by Microsoft SharePoint Foundation may become corrupted. The corrupted database may contain orphaned items. For example, a document may not have a parent document library or a list may not have a parent Microsoft SharePoint Foundation Web site. Consequently, you may be unable to create new items with the same URL as the orphaned items, and space in the content database will be consumed unnecessarily.
Aha! So I ran the Rule Settings at the bottom, then clicking on RUN now. Accessed the site again, no problems! Wow… Thought I’d look into this one a bit more. Interesting – try going here on the Central Admin: http://CentralAdministration:PORT/Lists/HealthRules/AllItems.aspx Seems I can now do some really ace things in Monitoring; like scheduling when jobs are to occur, enable and disable, and also force a repair! Going to come back soon and blog this more when I get more details!
One thing that you will find installing the Sharepoint 2010 BETA Installation is that things have changed concerning Standalone versus Complete installation.
Standalone build is usually the one to go for when you want a single server developer type environment and also all the SQL permissioning is done for you.
However, Complete installation allows you to finely tune the accounts used in SQL, and I always find that the best route to go personally.
Got a bit of a shock though when at the Specify Configuration Database Settings and filing in the Database Server, Name, Username and Password the following when clicking NEXT:
The specified user MyServerName\MyLocalAccount is a local account. Local accounts should only be used in stand alone mode.
Oh dear, so how to get around that? Time to use another new feature in 2010 – Sharepoint 2010 Management Shell which uses – wow Powershell!! This is availble in the shortcuts for Sharepoint 2010 on Start Programs etc.
Ok, so when running this up, enter the commands as follows:
New-SPConfigurationDatabase
This then brings up the cmdlet for that command. You will need to enter the values for the DatabaseName, Server, Farm Credentials and a Passphrase.
Once these have been entered, please be patient as the config db is created – can take up to 5 minutes!
Once done, all you need to do is rerun the Products Configuration Wizard – you’ll notice straight away that you can join the existing farm based on the the values you entered.
One note. For New-SPConfigurationDatabase to work SQL must be running Service Pack 2 or 3 – also, take a look at this link for more information:
Hope this helps!
Ok, had a right old hassle here, another blog will follow detailing how to resolve the dreaded ‘cannot access sts3’ etc.
Anyway, to business. What now follows is a step by step account of how to resolve getting a 403 Forbidden. I’ve tried this against various farms and it seems to work fine for me!
1. stsadm -o osearch -action stop –f
2. stsadm -o osearch -action start -role indexquery
3. stsadm -o execadmsvcjobs
So now I tried to access the search site and it told me that I had to assign an index server, of which I did, then I again from the index server had to run stsadm -o execadmsvcjobs.
At this point, I had to provide access to c:\windows\tasks, from the command line, on our index server for the local group WSS_WPG as follows
1. By running attrib c:\windows\tasks -s on the index server so as to be able to change the tasks system folder attributes.
2. Then I added the local group WSS_WPG with read and write access
3. And now take back the attributes of the tasks system folder to the way they were by running attrib c:\windows\tasks +s
Now to reset the SSP prior to running a full crawl on the index server
1: Set the Indexer in for the SSP to the servername of the sharepoint box
2: Go back into Search Settings on the SSP
3: Reset all Crawled Content
4: Go back into Content Sources
5: Start Full Crawls on Content Sources
Thought it high time I blog this. You may get errors like this following a DB move, for example, moving a content db from a sql box to a cluster / vice versa <grin>.
7888:
A runtime exception was detected. Details follow.
Message: Cannot insert duplicate key row in object ‘dbo.UserMemberships’ with unique index ‘CX_UserMemberships_RecordId_MemberGroupId_SID’.
The statement has been terminated.
Techinal Details:
System.Data.SqlClient.SqlException: Cannot insert duplicate key row in object ‘dbo.UserMemberships’ with unique index ‘CX_UserMemberships_RecordId_MemberGroupId_SID’.
The statement has been terminated.
5553:
failure trying to synch site [SITEGUID] for ContentDB [CONTENT DB GUID] WebApp [WEB APP GUID]. Exception message was Cannot insert duplicate key row in object ‘dbo.UserMemberships’ with unique index ‘CX_UserMemberships_RecordId_MemberGroupId_SID’.
The statement has been terminated.
Lots of diving off into the logs looking at the Timer and then back into SQL to see what syncs where going on revealed whats going on – I should have run preparetomove on the content db before moving it 🙂 – hence:
WHY:
This occurs when a site collection or a content database is moved from one web application to another without running the Preparetomove command first. Without running the Preparetomove command, the SSP thinks the site is new and tries to insert data into the UserMemberships table that already exists there. This causes SQL to throw a duplicate key error and causes the profile synchronization job to fail.
SOLUTION:
1. Open a command prompt and navigate to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN
2. Run ‘stsadm- o preparetomove -Site <
http://whatevertheguiltysiteis/> -OldContentDb <GUID of the contentdb listed in event log error>’
3. Run ‘stsadm -o sync -deleteolddatabases 0’
NOTE:
To get the Site relevant to the GUID you can obtain the content DB name which if you then look inside Application Management Content DB you will get an answer:
To do this I simply used a SQL script as follows:
SELECT Id, ClassId, ParentId, Name, Status, Version, Properties
FROM Objects
WHERE (Id = ‘The GUID from Event ID 5553’)
Hope this helps!
Someone said to me today ‘Hey – our Sharepoint Search system Sucks – I reckon Google Search is better, lets put that in now!’ – here’s my reply sorry if it turns into a rant hehe.
Implementing google search over sharepoint enterprise federated search just because it happens to be google is not complete justification and requires careful implementation. I for one cannot agree that an external search system be implemented just because people think the internal sharepoint search is might be not ‘working’ or is ‘crap’.
Its those people who are underestimating sharepoint and probably do not understand or wish to improve the current search system. The analogy is like putting a fiat car engine into a formula one car just because it might look neater; or using a hammer to cut fish.
The key thing to remember is that the search system in sharepoint is fundamental to its working – it can be manipulated, configured – google search cannot!
Sharepoint Search belongs to sharepoint – its core to everything – so in terms of manipulation and configuration to the enterprise it is straightforward. Microsoft lets you mess with all the levers and knobs in the underlying algorithm; Google gives you zero access. Nada! Google Search is usually a poor mans fix to the search tools that come with WSS (which is the FREE part of sharepoint).
Enterprise Federated Search gives us huge number of features mostly untapped to a company who has implemented sharepoint without defining taxonomy.
You’re always most certainly far better off tuning the deployment using the tools Microsoft provides rather than messing with the underlying algorithm and putting in something else. If you do change the algorithm, you need to be absolutely obsessive about measuring the overall improvements.
So, primary reasons why you should not implement external products (especially a different search engine!) on an internal system is simply because it requires resources technical and human to support; the information architecture must be complete; there could be increased risk of modification which increases the risk of breaking Sharepoint when say upgrading to another service release; it increases confusion since even say you was to to implement it on one farm and not others in the same organisation; it increases a training requirement.
Time to evangelise!SharePoint search includes High End Search (FAST): http://sharepoint.microsoft.com/en-us/product/capabilities/search/Pages/Fast-Search.aspx
SharePoint FAST Search includes out of the box
- Deep Refinement
- Thumbnails
- Similar Results
- Previews
- Sorting
- People Search
- Federation
Combine this with people and expertise gives you:
- Filter by title expertise and other attributes
- Phonetic name lookup
- Expertise Matching
- Real Time presence
- Find Recent Content
- Organisation Browsing
So you can:
1: Find People with address book search
2: Discover expertise – based on terms matched from mined outlook inbox data and sharepoint mysite profiles
3: Use MySite profile pages – recognise and track colleagues and make it easier to share content
Other points:
Fast is under our control
1: Breaks down content to smallest addressable chunks to build meaning
2: Understands file encoding, data formats and written languages
3: Supports at least 400 file formats and 80 languages
4: Normalises the content defined by a model we prescribe
5: Identifies structed and unstructed metadata in content
6: Maps document metadata to crawled properties
So, whilst people may not be happy with their search engine, other search hosted services are no closer to solving this problem than the on-premise search tools of its competitors. There is no concrete evidence that simply swopping search engines brings utopia to internal search. The key to fixing an internal search system is to structure and control its content expose that to a FAST which has the ability to create an index, which is fully supported – not to simply drop in an external hosted solution and hope with fingers crossed that a magic wand will sort things out.
Therefore:
1: Fix the content (taxonmony, information architecture, SEO) – make sure you have the right resources at hand – you may need an information architect to help!
2: Apply FAST search server to the SharePoint platform
3: Fix user adoption
4: Control the solution
Hi there,
In this article we’ll have a list of links and stuff that you will need to start looking at if you are interested in going down the Sharepoint 2010 route:
Technet Evaluation Centre Sharepoint 2010 Beta –
HEREGet Ready for Sharepoint 2010 – Software and Hardware Requirements –
HERESee the Video Demos –
HERECheck out the Evaluation Guide –
HEREGetting Started Videos –
HERESharepoint Docs on Technet –
HERE
When moving your sharepoint instance to another server group, watch out for synchronisation issues. For example, you may see a situation where old memberships from your old instance is still being shown.
The membership functionality strictly works off the users listed in the Members group of the SharePoint site. A point – if you are a owner of a site you may not see a membership update – The only thing we have to do now is insure the owner of the site is ALSO a member of the site in order for them to take advantage of the membership features.
You cannot directly edit the memberships or delete them from the UI. This information is taken from you being an member of a sharepoint site and is updated through Timer jobs.
You may have moved content database improperly. The ID for the content database is stored in the Config database. By not moving the content database properly you do not prepare the SSP for a new GUID, and the Timer Jobs will continue to try to sync with the old GUID not allowing us to sync with the new one.
The preparetomove operation was introduced before Infrastructure Update. Once SP2 is applied this is no longer required.
Try doing this:
a. Run the command stsadm -o sync -listolddatabases 1 You should then get a list of database GUID.
b. Run the command stsadm -o sync -deleteolddatabases 1 This will remove the record from the SSP database but will not touch the actual Content Database.
c. Then wait for the next sync and you should see memberships getting updated..
