Here is the link to the article and I welcome feedback.
Happy Memorial Day and Thank You to all Veterans!
Ok, I was thinking that I could quickly take a SharePoint 2007 content database, apply the minimum Service Pack 2 for WSS 3.0 and MOSS 2007, and then perform a database attachment within SharePoint 2010 in minutes while basking in the glory of the easy process. I should have known this is SharePoint and everything is earned in this world. 🙂
I rebooted all the web front end servers and application servers just to make sure my little SharePoint 2007 world had the right build number of 126.96.36.19921 within Central Admin. So I did a backup of the database and then moved the BAK file to the SharePoint 2010 Database instance and performed a simple restore. For extra incentive and I was the DBO in the environment, I placed the SP Farm Account DBO to make sure the attachment goes ok.
I ran the PowerShell commandlet Test-SPContentDatabase to verify the database. Then I got the error.
[box type=”warning”]Category: DatabaseValidation Error: True UpgradeBlocking: False Message: This database [SSPBeta] is too old and cannot be upgraded. Remedy: Upgrade this database to Windows SharePoint Services Version 3, SP2 or later. [/box]
[box type=”info”]So after I read multiple blogs, forums, etc.; I wanted to think outside-of-the-box. I tried an idea. “Maybe the commandlet needed a build number newer than 188.8.131.5221?”
So I got the April/2009 Cumulative update for WSS 3.0 and MOSS 2007. So I applied these two CU’s to the SharePoint 2007 Environment.
I verified I was on build number 184.108.40.20604. [/box]
Just like washing your hair. Rinse and Repeat.
So I did a backup of the database and then moved the BAK file to the SharePoint 2010 Database instance and performed a simple restore. For extra incentive and I was the DBO in the environment, I placed the SP Farm Account DBO to make sure the attachment goes ok.
I ran the PowerShell commandlet Test-SPContentDatabase to verify the database.
Resources for review:
I welcome any feedback.
Exception from HRESULT: 0x80040E14 error appeared on my SharePoint 2007 environment this weekend.
There are a variety of blogs I have found that fixes this issue. Each one stating the same thing.
[box type=”info”]1. Check the drive space for the SQL server logs for SharePoint. Clean out the space.
2. Check the drive space for the SQL server data files for SharePoint. Clean out the space.[/box]
This fixed my issue. I just wanted to pass along to my SharePoint community. 🙂
Let’s see; when you try to run an index within SharePoint 2007 it should work as advertise right? Well there is this topic and fix called, the loop back bug.
Below is the registry hack to get around the issue. I apply this to all SharePoint 2007 WFE’s.
How to prevent a double loop back when authenticating against a local server Internet Explorer instance of SharePoint: (Here is the link to the Microsoft Knowledge Article.)
- Go to Start, Run, and type, “regedit”
- Navigate HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
- Right-click Lsa, point to New, and then click DWORD Value.
- Type DisableLoopbackCheck, and then press ENTER.
- Right-click DisableLoopbackCheck, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Quit Registry Editor
I have my ticket and plan to be in attendance to SharePoint Saturday on August 14th in Columbus, Ohio.
Here is the official link.