Migration Issue - Content Database is in compatibility range and upgrade is recommended?

I recently had to recover from a disaster with one of our SharePoint testing environments. (This happens to be the only testing environment that is not on virtual hardware.) Fortunately, I do quality assurance testing for a disaster recovery product and it wasn’t long before I had new hardware for the failing database server and could rebuild the farm. I did run into some interesting issues however. After I reinstalled the WFEs and had central administration working again, I reattached the content databases that I had recovered. After all of this my farm worked fine and I had access to all of my Site Collections again. Disaster averted. The health analyzer on the farm kept warning me about upgrading databases though. Specifically the error message that I got was the following; "Database is in compatibility range and upgrade is recommended."  Seems simple enough. There are Powershell commands that I can use to upgrade the databases.
$contentdb = Get-SPContentDatabase | Where-Object {$_.Name -eq "WSS_Content"}
Upgrade-SPContentDatabase -Identity $contentdb
I ran those commands from a Powershell prompt (the SharePoint 2010 Management Shell since that one automatically loads the SharePoint snap-in.) I was then immediately irritated when the upgrade failed.
WARNING: Database [SPContentDatabase Name=WSS_Content] does not need to be upgraded.
So, Central Administration tells me that my database needs to be upgraded, and then when I try to update the database, it tells me that it doesn’t need to be upgraded. I was a little confused. I figured I would try a different approach, so I ran PSConfig on the farm with the “build to build” switch.
psconfig -cmd upgrade -inplace b2b -wait -force
This only resulted in more errors.
I then tried to detach and reattach the content databases, since, when attaching a content db, SharePoint should typically upgrade the database if it needs it. That didn’t work either.
I talked with Sean McDonough for a few minutes about the situation and he enlightened me that there is a chance that it is not my content databases that need upgrading. How do you really know though? Time to poke into your content databases to tell for sure.  The first database you need to check is your SharePoint Config database since that is the one that shows you what version your farm is currently using, be it a service pack, or one of the myriad cumulative updates. Run the following in a Sequel Server Management Studio Query.
use SharePoint_Config
SELECT Version
FROM Versions
WHERE VersionId = ’00000000-0000-0000-0000-000000000000′
ORDER BY Id DESC
This will show you every version that your farm has evolved through. Mine showed one version; 14.0.4762.1000. (This is incidentally the RTM version of SharePoint 2010) I then ran the same query against one of my databases that supposedly needed to be upgraded and found more than one version. 4762 was there, but so was 5128. It would seem that it wasn’t my content databases that needed to be upgraded, but rather the rest of my farm. Now my problem was figuring out which version I needed to end up with after upgrading. Fortunately, Todd Klindt has an awesome reference page here that will tell you which Service Pack or Cumulative Update each version number means with a link to download what you need. I downloaded the Cumulative Update for October 2010, installed it on my farm, and then ran psconfig again to finish everything up. All of those “database needs upgrade” errors were gone and the health analyzer on my farm settled down again. Just to be sure I went to the Farm’s Central Administration, then to “Upgrade and Migration” and clicked on “Review Database status.”  Every database stated “No Action required” instead of the upgrade message.
So, if you have to recover a farm and reattach your databases, or you are attaching your content databases to a new farm, keep in mind that if SharePoint tells you that databases need to be upgraded, it might not be the databases that are in need of an upgrade.
Many thanks to Sean McDonough for his input, and to Todd Klindt for his blog for reference.

Sharepoint Patches Issues in Index Server

Issue

Unable to install the security patches , it gives , and error "  Installation is not detected "  We are trying to install KB2810059 , KB2760408 , KB2760777

Product / Version / Service Pack: SP 2010

Operating System / Service Pack: win 2008 R2

Farm Configuration: 14.0.6137.5002

Database Used:

Additional technologies:

Resolution

Once we are able to  install the above mentioned patches on the STG Index server  ,and complete the configuration wizard , we will consider this case to be resolved.

Troubleshooting Done

Ø  Created the EA

Ø  When we are trying to install the patches, we are getting error, installation is not detected.

Ø  The patches were installed successfully on the other server of the farm

Ø  We earlier tried to remove the server from the farm from CA

Ø  We ran the configuration wizard , and removed the server from the farm

Ø  We ran the ROI scan , and got the o/p

Review Items

============

Error:                       Product {90140000-1140-0411-1000-0000000FF1CE} - Microsoft Office Web Apps Shared Coms Japanese Language Pack: Local cached .msi appears to be missing: C:\Windows\Installer\2509144.msi

Error:                       Product {90140000-1080-0411-1000-0000000FF1CE} - Microsoft Shared Coms Japanese Language Pack: Local cached .msi appears to be missing: C:\Windows\Installer\2509152.msi

Error:                       Product {90140000-1080-0409-1000-0000000FF1CE} - Microsoft Shared Coms English Language Pack: Local cached .msi appears to be missing: C:\Windows\Installer\250904c.msi

Error:                       Product {90140000-10B0-0411-1000-0000000FF1CE} - Microsoft Project Server Japanese Language Pack: Local cached .msi appears to be missing: C:\Windows\Installer\250913d.msi

Error:                       Product {90140000-1103-0411-1000-0000000FF1CE} - Microsoft Document Lifecycle Components Japanese Language Pack: Local cached .msi appears to be missing: C:\Windows\Installer\25091a7.msi

Error:                       Product {90140000-1103-0409-1000-0000000FF1CE} - Microsoft Document Lifecycle Components English Language Pack: Local cached .msi appears to be missing: C:\Windows\Installer\2509098.msi

Error:                       Product {90140000-1123-0000-1000-0000000FF1CE} - Microsoft Access Services Server: Local cached .msi appears to be missing: C:\Windows\Installer\2509101.msi

Error:                       Product {90140000-10F3-0000-1000-0000000FF1CE} - Microsoft Visio Services Web Front End Components: Local cached .msi appears to be missing: C:\Windows\Installer\25090e6.msi

Error:                       Product {90140000-1014-0000-1000-0000000FF1CE} - Microsoft SharePoint Foundation 2010 Core: Local cached .msi appears to be missing: C:\Windows\Installer\25090a8.msi

Error:                       Product {90140000-1144-0000-1000-0000000FF1CE} - Microsoft Office Web Apps Web Front End Components: Local cached .msi appears to be missing: C:\Windows\Installer\25091ed.msi

Error:                       Product {90140000-1015-0411-1000-0000000FF1CE} - Microsoft SharePoint Foundation 2010 1041 Lang Pack: Local cached .msi appears to be missing: C:\Windows\Installer\250914a.msi

Error:                       Product {90140000-1015-0409-1000-0000000FF1CE} - Microsoft SharePoint Foundation 2010 1033 Lang Pack: Local cached .msi appears to be missing: C:\Windows\Installer\2509021.msi

Ø  We see lot of missing installer file , we tried to install the same from a working server

Ø  Cscript Oputil.vbs /repaircache /srestorelocation=\\servername\c$\windows\installer

Ø  After which the same got copied successfully

Ø  We ran the config wizard , which was successful with some error.

Ø  We checked the upgrade log and it was referencing to a content database

Ø  We detached the content database  , and ran the upgrade , we still got some error about the logs been full in the database

Ø  We changed the recovery model from simple full

Ø  Ran the configuration wizard and it was successful.

Additional Information

http://blogs.technet.com/b/patrick_heyde/archive/2010/08/30/sharepoint-2010-patching-upgrade-part-2-which-patch-level-build-level-is-installed-amp-what-s-their-history.aspx

http://technet.microsoft.com/en-us/library/ff607813.aspx

USER PROFILE CONFIGURATION IN PRODUCTION SERVER

In the previous implementation, the profile import job, that was carried out during SharePoint user profile service had some inconsistencies due to which the address book on SharePoint showed up mixed names like instead of displaying . This operation is required to fix the same. This task does not require any outage and can be included within the same nightly batch job.

SharePoint 2010 Production Server User Profile Services Configuration Steps

Note: Before going to make any change in User Profile Application first disabled the My Sites Scheduler from Central Administration Monitoring.

Step 1: Login to the SharePoint 2010 Production Application Server.

Server Name: SharePoint Application Server

Step 2: Open the Central Administration à Go to “Application Management” à Click “Manage Service Application” à Click “User Profile Service Application”

Step 3: In “User Profile Service Application” à Click “Configure Synchronization Connections” under “Synchronization”

Step 4: Delete Existing Connect ion.

Note: If unable to delete the use below command to delete the Connection.

1.    PS C:\Users\ServiceAccount> Get-SPDatabase > C:\Database.txt

2.    PS C:\Users\ServiceAccount> $syncdb=Get-SPDatabase

Note: Find out Sync database name using first command path

3.    PS C:\Users\ServiceAccount>$syncdb.Unprovision()

4.    PS C:\Users\ServiceAccount>$syncdb.Status='Offline'

5.     PS C:\Users\ServiceAccount>$upa=Get-SPServiceApplication

Note: Using Get-SPServiceapplication command to find out user profile application ID

6.     PS C:\Users\ServiceAccount> $upa.ResetSynchronizationMachine()

7.     PS C:\Users\ServiceAccount> $upa.ResetSynchronizationDatabase()

8.     PS C:\Users\ServiceAccount> $syncdb.Provision()

 Step 5: Change NetBIOS Setup from False to true

1.  Using below Power Shell command to find out User Profile Application Name.

Command:  PS C:\Users\ServiceAccount> Get-SPServiceapplication

2.    Using below command to find out Netbios setup true or False.

Note: If output false then using PS command to change.

 PS C:\Users\ServiceAccount> (Get-SPServiceApplication ).NetBIOSDomainnamesEnabled

3.     PS C:\Users\ServiceAccount> $upsa = Get-SPServiceApplication -Id

4.     PS C:\Users\ServiceAccount> $upsa.NetBIOSDomainNamesEnabled=1

5.     PS C:\Users\ServiceAccount> $upsa.Update()

6.     PS C:\Users\ServiceAccount> (Get-SPServiceApplication ).NetBIOSDomainnamesEnabled 

Step 6: Stop and Start the User Profile Synchronization Service

1.  Go to Central Administration à Click “Manage Services and Server” under System Settings

2.  Stop and Start the “User Profile Synchronization Service” Services.

Step 7: Create the new Connection in User Profile Services

1.  Go to the User Profile Application (Refer Step 1)

2.  Click “Create New Connection” and parameter information as below.

1.1      Connection Name – DOMAIN NAME

1.2      Forest name: ********

1.3      Specify a domain controller: DomainName.corp.nai.org

1.4      Account Name: DomainName\ServiceName

1.5      Account Password: xxxxxxxxx

3.  Click to “Populate Containers”

4.  Find out NAI and select and uncheck Windows7.0 Machines.

5.  Finally Click Ok

Step 8: Back to the User Profile Application Page and click Start Full Profile Synchronization.

Step 9: Two times you have complete the full start Profile Synchronization and one time Incremental.

How to identify and clean up orphan sites in sharepoint

Orphan sites are of two types, Content DB and Config DB orphan sites.

Content DB orphan sites have entries of a site collection in content DB but no entries are found in Config Database siteMap table.

Config DB orphan sites have entries of site collection in sitemap table, but no entries for the site exists in content DB. This type of orphan’s are more problematic and can even cause your search crawls to fails.

 ·        Identification of orphan sites by running SQL query

Run preupgrade check on your farm which will generate report with a list of orphan sites. Generally this reports only on content DB orphan sites and not on Config DB orphan sites.

Alternatively you can use the following query to identify all orphan sites in a farm

Use TEMPDB

Drop table orphanlist

CREATE TABLE [dbo].[orphanlist](

[farm] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,

[databasename] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,

[SiteID] [uniqueidentifier] NULL,

[sitepath] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,

[type] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL

)

drop table orphan_hopper  

declare  

@dbname as varchar(250), 

@cmdstr as varchar(2000), 

@dbid as varchar(250),

@configdb as varchar(250)  

select @configdb = 'YOUR_config_db_HERE'

select @cmdstr = 

'select distinct b.name as ''databasename'', b.id as ''dbid'' into orphan_hopper 

from 

 [' + @configdb + '].dbo.sitemap as a inner join   

 [' + @configdb + '].dbo.objects as b on a.databaseid=b.id inner join   

 [' + @configdb + '].dbo.objects as c on c.id=a.applicationid inner join   

 [' + @configdb + '].dbo.objects as d on b.parentid=d.id inner join   

 [' + @configdb + '].dbo.objects as e on d.parentid=e.id  '  

exec (@cmdstr)    

DECLARE DBCursor CURSOR For 

  Select databasename, dbid 

  From orphan_hopper 

OPEN DBCursor 

FETCH NEXT FROM DBCursor into @DBName, @dbid 

WHILE @@FETCH_STATUS =0 

BEGIN 

 INSERT INTO orphanlist([Type], farm, databasename,[sitepath], SiteID) 

 EXEC 

  (' 

select ''Potential ConfigDB orphan:'' + '''+@dbname+'''   as [Type], '''+@configdb+''' as [farm], '''+@dbname+''' as [databasename],path as [sitepath], id as [SiteID] from ['+@configdb+'].dbo.sitemap where id not in (select id from ['+@dbname+'].dbo.sites) and databaseid = '''+@dbid+''' 

union 

select ''Potential ConfigDB orphan:'' + '''+@dbname+'''   as [Type], '''+@configdb+''' as [farm], '''+@dbname+''' as [databasename],path as [sitepath], id as [SiteID] from ['+@configdb+'].dbo.sitemap where id not in (select siteid from ['+@dbname+'].dbo.webs where parentwebid is null) and databaseid = '''+@dbid+''' 

union 

select ''Potential ContentDB orphans:'' + '''+@dbname+''' as [Type], '''+@configdb+''' as [farm], '''+@dbname+''' as [databasename],fullurl as [sitepath], siteid as [SiteID] from ['+@dbname+'].dbo.webs where parentwebid is null and siteid not in (select id from ['+@configdb+'].dbo.sitemap where databaseid = '''+@dbid+''') 

union 

select ''Potential ContentDB orphan:'' + '''+@dbname+'''  as [Type], '''+@configdb+''' as [farm], '''+@dbname+''' as [databasename],fullurl as [sitepath], siteid as [SiteID] from ['+@dbname+'].dbo.webs where parentwebid is null and siteid not in (select id from ['+@dbname+'].dbo.sites) 

') 

 FETCH NEXT FROM DBCursor into @DBName, @dbid 

END 

CLOSE DBCursor 

DEALLOCATE DBCursor 

select * from orphanlist 

Drop table orphanlist

·        Identification of orphan site type

SQL query output should be pulled into excel and then based on "type" information column determine if the orphan site is a Config DB and Content DB type.

·        Steps to clean up content DB orphan sites

Run stsadm deletesite to clean up Content DB orphan site.

Note – Take back up of the content DB’s before deleting the orphan sites.

stsadm -o deletesite -databaseserver "instanceName" -databasename  "[ContentDBName]" -siteid "[Site ID]"

·        Steps to clean up Config DB orphan site

a.       Identify the content DB for the orphan site

b.      Make sure that search crawls are not running. Also make sure that user profile import and audience compilation is not running.

c.       Detach the content database from sharepoint central admin

d.      Reattach the content database using “stsadm addcontentDB”

·        Rerun the preupgradeCheck to confirm that orphan sites have been cleaned up.

SharePoint 2010 Infopath Print Button

Once you have your Infopath form put together and published to a List, go to the List page.

1. Click on the “List” tab under List Tools
2. Click on the drop down arrow on the “Modify Form Webparts” button
3. Select “(Item) Display Form”
4. This will take you to an edit page screen with your Infopath form set as a webpart
5. Add a “Content Editor Webpart” to the page
6. Edit your new webpart’s source and paste in the following:


input type="button" value=" Print" onclick="window.print();return false;"

Note:

This adds a print button to the page that uses the default print call within a browser.  Since we edited the “Display” form, the button will not appear if a user is editing the form or creating a new item.
tags are not required

Finding List GUID ID

There will be several times when you need the Guid or ID of list or view - for example while passing these in for adding, updating or deleting list item in SharePoint through List service or when setting the Task list to be used with SharePoint Designer Workflows. Here is a simple way to accomplish the same.



For List:


1.Navigate SharePoint site


2.From “Settings” menu select “List Settings”


3.Copy the entire URL and paste in any text editor


It would look something like this:
http://mossserver/_layouts/listedit.aspx?List=%7B2761B4AF%2D6452%2D448F%2DADF6%2D6FBA18DAAB81%7D
1.Delete everying before and including “List=”.


2.Change “%7B” to “{”


3.Change all “%2D” to “-“


4.Chnage “%7D” to “}”


You are now left with the following:
{2761B4AF-6452-448F-ADF6-6FBA18DAAB81}
_


For View:
For View's GUID you can perform the same steps
_


Note:
In case of View its little tedious, because when you will copy the link in text editor it will also consist of GUID of list and url of Source.


For example it would be something like this


http://mossserver/_layouts/listedit.aspx?List=%7B2761B4AF%2D6452%2D448F%2DADF6%2D6FBA18DAAB81%7D&View=%7B58B8F4B8%2DA2F6%2D4E3C%2D9F1F%2D4657F664B4D2%7D&Source=%252F%255Flayouts%252Flistedit%252Easpx%253FList%253D%25257B76E983B9%25252D5FCC%25252D4D3E%25252D8DE9%25252D671932BB3308%25257D


So you have to be careful while removing unnecessary part from the copied link

Attempted to perform an unauthorized operation

Issue Details:

 System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.



Solution:

Check if the current user has appropriate permissions on SharePoint site.


The Web Application should be configured configured with Integrated Windows Authentication and anonymous access should be disabled/unchecked.


Go to IIS —> Website —> Properties —> Directory Security         —> Uncheck Enable Anonymous Access