Resolution – ‘Local accounts should only be used in stand alone mode’ – How to fix that!

Resolution – ‘Local accounts should only be used in stand alone mode’ – How to fix that!

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!
Solve 403 FORBIDDEN when trying to access SEARCH Administration SharePoint 2007

Solve 403 FORBIDDEN when trying to access SEARCH Administration SharePoint 2007

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

EVENT 7888 and 5553 – Failure trying to synch site and Cannot insert duplicate key row in object

EVENT 7888 and 5553 – Failure trying to synch site and Cannot insert duplicate key row in object

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!